1

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

我必须做的：

  1. 使用 Soap Web Service 接收消息并将消息放入消息队列 - 由Service完成
  2. 从队列中检索消息 - 由服务完成
  3. 转到数据库，通过tenderId 检索一个Tender 对象或创建一个新的Tender - 由Repository完成
  4. 用消息中的值填充 Tender 对象的字段 - 由Domain Object Tender完成
  5. 将投标保存到数据库 - 由存储库完成

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

4

3 回答 3

3

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

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

不要太担心——不管你有多好，都需要几次失败才能把它做好:)

于 2011-11-02T09:15:38.207 回答
2

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

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

于 2011-11-01T21:17:12.330 回答
1

猜猜你并不孤单有这种想法。通常在我的模型中最终是验证、聚合管理，而且我也尝试将重点放在值对象上。尽量减少自动属性，邀请您不假思索地进行快速开发...我前段时间在我的博客上写了一篇关于此的文章... http://magnusbackeus.wordpress.com/2011/05/31/preventing-贫血域模型在哪里是我的模型行为/

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

于 2011-11-02T11:21:59.737 回答