我一直在阅读有关DDD的信息，我认为我可能错误地使用服务，或者至少以不那么理想的方式使用服务。我的服务类往往有很多包含存储库引用的实例变量，它们似乎做了很多工作（即有很多方法）。
建议创建更有针对性的服务是否明智？像每个服务执行某些特定逻辑的方法一样？此外，服务类应该将实例变量存储到其他实体吗？我读了一些关于无状态服务的内容，我不确定是否通过使用这些实例变量来破坏该规则。
谢谢！
答案 0 :(得分：14)
我的服务类往往相当 一些实例变量......
这不一定是代码味道。如果您的服务需要很多依赖项来完成其工作，那么这只是一个事实。
......他们似乎做了很多工作（即 有很多方法。）
建议创建更有针对性的服务吗？
作为一般规则，您可以更精细地制作服务接口（即方法越少），越好（通过一个界面搜索五十种方法，寻找你想要调用的那个？） ）。但除非您作为公共API发布，否则您可以在进行时细化服务接口的粒度。通常，在启动项目时，我将从一项服务开始，并随着时间的推移将其拆分。如果您是这些服务的消费者，那么当您开始感受到界面变得越来越大的痛苦时，您就会知道是时候将其分解了。当然，如果 是一个公共API，那么你将需要做更多的前期设计。
此外，服务类是否应将实例变量存储到其他实体？我读了一些关于无状态服务的内容，我不确定是否通过使用这些实例变量来破坏该规则。
将依赖项存储为实例变量并不一定意味着您的服务不是无状态的，只要实例变量也是无状态的。要被视为无状态，对服务的方法调用决不能以任何方式依赖于之前被调用的方法。您应该能够加载单个服务实例，并为您的应用程序共享它（即无状态服务的实例不应该特定于特定用户的会话）。换句话说，您的服务不应该在方法调用之间保持任何状态。将无状态存储库依赖项作为变量存储在服务实例上不会违反此要求。
无状态服务是一个理想的目标，是没有状态大大降低了bug的可能性。它通过限制测试用例来改变传入的参数，而不必担心服务的先前状态，从而简化了服务方法的测试。它还可以提供性能优势。
答案 1 :(得分：0)
我建议阅读依赖注入，控制反转等。
这是福勒的文章：http://martinfowler.com/articles/injection.html，虽然我总是发现他有点过头了。我将尝试使用代表使用DI / IoC容器的教程。