DDD：聚合边界与组合便利性。

Question

我正在开始一个新的 DDD 项目，但我觉得我还没有真正掌握这些概念。到目前为止，我的域中有两个聚合根，Recipe 和 Food。他们的关系是这样的：

`Recipe`->*`Ingredient`->`Food`

Ingredient 是数量 + Food

我认为可能在 Recipe 聚合中包含聚合 (Food) 很糟糕，但它确实很方便，因为它允许通过导航关系来计算食谱的营养价值。

我也不存储计算结果，我每次都重新计算，所以如果食物发生变化，食谱会自动更新，我不知道这是否是个好主意。

另外，是否可以为Recipe+Ingredient 提供一个存储库，因为它们在同一个聚合中，我必须加载所有成分，这样我才能在配方的构造函数中传递它们？

Answer 1

是否可以为 Recipe+Ingredient 提供一个存储库，因为它们在同一个聚合中，并且我必须加载所有成分，以便无论如何我都可以将它们传递给配方的构造函数？

这是大多数人所期望的 - 一个单一的存储库，可以加载包含在聚合边界内的所有状态。

我认为可能在 Recipe 聚合中包含聚合（食物）是不好的，但它真的很方便，因为它允许通过导航关系来计算食谱的营养价值。

• 坏处大于好处。
• 这在使用简化域来发现如何进行 DDD 时并不明显。

聚合的动机是限制模型中数据更改的方式，以便每次更改都使模型处于内部一致的状态。

如果您的域没有任何要强制执行的一致性约束（例如，当您的数据模型实际上只是一个数据库，并且数据模型对提议的更改没有否决权），那么问题空间不提供在选择良好的聚合边界方面有很多指导。

聚合背后的基本原则是您正在创建一种数据防火墙，您永远不必担心对 this 聚合的更改会违反 that的规则> 聚合。这意味着，除其他外，任何两个聚合都不应该共享可变数据。

共享值很好 - 每个聚合都有自己的值的不可变副本，并且更改一个聚合中的值根本不会影响另一个聚合。共享实体不好，因为实体是可变的。

拥有一个模型可以很方便地生成带有错误答案的查询，但其价值不如确保答案正确的模型。

通常情况下，一个聚合将通过 ID 引用另一个聚合。所以你的食谱看起来像

`Recipe`->*`Ingredient`->`Id<Food>`

Id<Food> 只是另一种不可变值类型；食谱可以很容易地改变它使用的食物，但它不能以任何方式改变食物。这反过来意味着您永远不必担心更改一个 Recipe 会破坏另一个。