如何避免贫血的领域模型？答案

【问题标题】：how to avoid anemic domain model?如何避免贫血的领域模型？
【发布时间】：2011-12-19 19:32:59
【问题描述】：

我正在尝试通过示例学习领域驱动设计，我需要您的建议。假设我有一个名为 Tender 的实体。我收到来自外部服务的肥皂消息；该消息包含有关投标的所有信息（tenderId，tenderSum，...）

我必须做的：

我尝试以正确的方式进行操作，但最后我发现，大部分代码都存在于服务、存储库等中。我真的很困惑。我做错了什么？我应该在域对象中做所有这些事情吗？

【问题讨论】：

【解决方案1】：

猜想你并不孤单有这种想法。通常在我的模型中最终是验证、聚合管理，而且我也尝试将重点放在值对象上。尽量减少汽车属性，邀请您不假思索地快速发展... 前段时间我在我的博客上写了一篇关于这个的文章... http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/

但这是一项迭代工作，需要找到合适的模型。准备好进行大量的重构......

【讨论】：

【解决方案2】：

DDD 中的某些实体/值对象的行为很少见并不少见。我几乎可以肯定，在任何项目中，您至少会有一些实体/VO，它们只有一些构造逻辑并且是不可变的。这些不是 DDD 的主要关注点。

您应该专注于识别和（重新）定义您的限界上下文和聚合。您会在网上找到很多关于此的信息（dddcommunity 是一个很好的起点，但我强烈建议您至少多看几次 Eric Evans、Udi Dahan 和 Greg Young 的所有视频）。

别太担心——无论你有多优秀，都需要几次失败才能把它做好:)

【讨论】：

【解决方案3】：

我发现，随着模型的发展，服务中的所有事物通常会随着时间而改变。在您的示例中，一种选择可能是让您的实体的方法成员名为Tender.LoadValuesFrom[ServiceName](val1, val1, etc)（提供的服务名称在域中具有意义）。

这样至少你让实体负责加载它自己的值。有时奇怪的服务会显得乏力。如果它无处不在，或者感觉很尴尬，那么它可能是在试图告诉你一些事情。否则我不会太强调它。

【讨论】：