domain-driven-design - 我是否正确使用服务层？

Question

我一直在阅读 DDD，我认为我可能错误地使用了服务，或者至少以不太理想的方式使用了服务。我的服务类往往有很多包含存储库引用的实例变量，它们似乎做了很多工作(即有很多方法)。

创建更有针对性的服务是否可取？就像每个服务执行某种特定逻辑的一种方法一样？此外，服务类是否应该将实例变量存储到其他实体？我读过一些关于服务是无状态的，我不确定我是否通过拥有这些实例变量而违反了该规则。

谢谢!

Answer 1

My service classes tend to have quite a few instance variables...

这不一定是代码气味。如果您的服务需要许多依赖项来完成其工作，那么这就是一个事实。

...they seem to do a lot of work (i.e have a lot of methods).

Is it advisable to create more focused services?

作为一般规则，您可以使您的服务接口(interface)越细化(即方法越少)越好(曾经必须在一个接口(interface)中搜索五十个方法来寻找您想要调用的方法？)。但是，除非您作为公共(public) API 发布，否则您的服务接口(interface)的粒度可以随着您的进行而改进。通常，在开始一个项目时，我会从一项服务开始，然后随着时间的推移将其拆分。如果你是这些服务的消费者，那么当你开始感受到接口(interface)变大的痛苦时，你就会知道是时候分解它了。当然，如果这是一个公共(public) API，那么您将不得不做更多的前期设计。

Also, should service classes store instance variables to other entities? I read something about services being stateless, I'm not sure if I am breaking that rule by having those instance variables.

将依赖项存储为实例变量并不一定意味着您的服务不是无状态的，只要实例变量也是无状态的。要被认为是无状态的，服务上的方法调用不能以任何方式依赖于之前被调用的方法。您应该能够加载单个服务实例，并为您的应用程序共享它(即，无状态服务的实例不应特定于特定用户的 session )。换句话说，您的服务不应该在方法调用之间保持任何状态。将无状态存储库依赖项作为变量存储在服务实例上并不违反此要求。
无状态服务是一个理想目标的原因是，没有状态大大降低了出现错误的可能性。它通过限制测试用例改变传入的参数来简化服务方法的测试，而不必担心服务的先前状态。它还可以提供性能优势。