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

Question

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

Answer 1

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

Toran Billups给出了类似的回答here，Jimmy Bogard写了一篇不错的博文here。

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

Answer 2

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

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

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

我建议采用更自然的方法。只是开始建模事物，不要问自己它是AR，还是价值对象，或者应该是服务等等。当你进步时，你会清楚地知道。

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