我正在尝试设计一个包含两个丰富模型的域层（贫血模型是不好的 OO 实践）。我还从 DDD 中了解到，它不排除服务对象，并且良好的领域层设计是领域逻辑拆分为领域模型和服务对象的健康平衡。不过我想知道，如果业务逻辑应该在领域模型和服务对象之间划分，应该在哪里划线？换句话说，我如何知道一个业务逻辑属于一个领域模型还是一个服务对象？是否有一条经验法则规定某些行为应该属于领域模型，而其他行为属于服务对象？请让我知道您是否可以提供一点提示，谢谢。
【问题讨论】：
标签： service model dns domain-driven-design business-logic
【讨论】：
良好的领域层设计可以正确地为领域概念和用例建模。由您决定什么是聚合根 (AR) 以及什么是服务。每个人都有自己的经验和喜好。
就我个人而言，我使用服务来实现用例。这意味着它们具有状态，虽然非常不可变，但状态是一个实现细节（我可以使用静态方法编写相同的东西，将所有的 deps 作为方法的参数传递，而不是在构造函数中注入所需的存储库和其他服务）。
最重要的是确保您了解业务概念、行为和用例。这应该是显而易见的，很多人对此很肤浅，结果设计非常错误且难以维护。
我建议采用更自然的方法。刚开始建模，不要问自己它是 AR，还是价值对象，或者它应该是服务等。随着你的进步，你会变得很清楚。
您能做的最糟糕的事情就是想出一些人为的规则/约束，并根据这些规则为您的域（实际上是整个应用程序）建模。 DDD 是关于让领域驱动设计。术语和技术细节是实现细节，可以随时更改，请勿将其用作设计指南。
【讨论】：