域模型和服务对象中的业务/域逻辑

Question

我试图设计一个具有丰富模型（贫血模型是不好的OO实践）的领域层。我还从DDD了解到，它不排除服务对象，并且良好的领域层设计是将领域逻辑分成领域模型和服务对象的健康平衡。不过，如果业务逻辑应该在域模型和服务对象之间划分，那么应该在哪里绘制线？换句话说，我如何知道业务逻辑是属于域模型还是服务对象？是否有经验法则规定某些行为应该转到域模型而其他行为属于服务对象？请让我知道你是否可以提供一点点提示，谢谢。

Answer 1

由于域服务是域模型的一部分，因此我假定您的意思是域服务与域对象。

Toran Billups给出了类似的回答here，Jimmy Bogard博客文章here。

作为一般的经验法则：域服务是无状态的，而域对象有状态。因此，任何依赖于内部状态的东西都会进入域对象，不依赖于当前状态和/或概念上不适合单个域对象的概念将由域服务建模。

Answer 2

良好的领域层设计正确地模拟领域概念和用例。由您决定什么是聚合根（AR）以及作为服务的资格。每个人都有自己的经验和喜好。

个人而言，我使用服务来实现用例。这意味着它们具有状态，虽然非常不可变，状态是实现细节（我可以用静态方法写入相同的事情，将所有的deps作为方法的参数传递，而不是在构造函数中注入必需的存储库和其他服务）。

最重要的是要确保您了解业务概念，行为和用例。这应该是显而易见的，许多人对此很浅薄，而且结果的设计很不妥，难以维护。

我建议采用更自然的方法。只需开始建模，不要问自己它是一个AR，还是价值对象，或者它应该是一个服务等等。随着你的进步，你会很清楚。

你可以做的最糟糕的事情是提出一些人为的规则/约束，并根据这些规则为你的域（和实际的整个应用）建模。 DDD是关于让域驱动设计。术语和技术细节是实现细节，可随时更改，不要将它们用作设计指南。