domain-driven-design - 如何在 DDD 中使用巨大的域类？

Question

当您以 OO/DDD 风格开发架构并对某些领域实体进行建模时，例如您将与订单相关的整个逻辑放入订单实体的订单实体。
但是当应用程序变得越来越复杂时，Order 实体收集的逻辑越来越多，这个类变得非常庞大。
与贫血模型相比，是的，它显然是一种反模式，但是所有这些庞大的逻辑都在不同的服务中分离。

可以处理巨大的域实体还是我理解错误？

Answer 1

当您尝试创建丰富的领域模型时，请将实体集中在身份和生命周期上，从而尽量避免它们因属性或行为而变得臃肿。

域服务可能是放置行为的地方，但我倾向于看到许多域服务方法的行为可以更好地分配给值对象，因此我不会通过将行为移动到域服务来开始重构。领域服务往往作为直接的外观/适配器在与当前领域模型之外的事物的连接之前工作得最好(即掩盖基础设施问题)。

您也可以将行为放在应用程序服务中，但要问自己该行为是否属于域模型之外。作为一般规则，尝试将应用程序服务更多地集中在跨实体、域服务、存储库的编排式任务上。

当你遇到一个臃肿的实体时，首先要做的是寻找一组有凝聚力的实体属性和相关行为的集合，并通过将这些隐含的概念提取到值对象中来使它们变得明确。然后实体可以将其行为委托(delegate)给这些值对象。

由于我们都倾向于对实体更满意，因此请尝试更偏向于值对象，以便您获得值对象提供的不变性、封装性和可组合性的好处——使您走向更灵活的设计。

值对象使您能够将更具功能性的样式(例如，无副作用的函数)合并到您的域模型中，从而使您的实体免于处理将复杂行为添加到管理身份和生命周期的负担中的复杂性。请参阅 Eric Evan 的 http://domainlanguage.com/ddd/patterns/ 中的实体和值对象的模式摘要。和蓝皮书了解更多详情。