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