如何避免贫血域模型？

Question

我正在努力学习领域驱动设计的例子，我需要你的建议。假设我有一个叫Tender的实体。我从外部服务接收Soap消息；该消息包含有关招标的所有信息(tenderId、tenderSum、.)

我要做的是：

1. 使用Service接收消息并将消息放入消息队列-由服务完成
2. 从队列中撤回消息-由服务完成
3. 转到数据库，通过tenderId检索投标对象，或创建由Repository完成的新招标
4. 用来自域对象投标者完成的消息的值填充投标对象的字段
5. 将招标保存到数据库-由Repository完成

我试着用正确的方式做这件事，但最后我发现，大多数代码都存在于服务、存储库等中，我真的很困惑。我做错什么了？我应该在域对象中做所有这些事情吗？

Answer 1

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

您应该专注于识别和(重新)定义有界的上下文和集合。你会在网上找到很多关于这方面的信息( 学步社区是一个很好的起点，但我强烈建议你至少多看几次从Evans、Udi Dahan和Greg可以找到的视频)。

不要太担心--不管你有多好，要想把它做好，需要几次失败:)

Answer 2

我发现，随着模型的发展，服务中的一切都会随着时间的推移而发生变化。在您的示例中，一个选项可能是拥有一个名为Tender.LoadValuesFrom[ServiceName](val1, val1, etc)的实体的方法成员(提供的服务名称在域中有意义)。

这样，至少要让实体负责加载自己的值。有时，奇怪的服务会显得贫血。如果它到处都发生，或者感觉很尴尬，那么它很可能是想告诉你什么。否则我不会过分强调这件事。

Answer 3

我想你不是唯一有这种想法的人。在我的模型中，通常的结果是验证、聚合管理，而且我还试图将大量精力放在值对象上。尽量减少汽车的特性，邀请你快速发展而不去想.不久前我在博客上写了一篇文章.http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/

但这是一个迭代的工作，找到正确的模型。准备做很多重构..。