reference

Question

我目前正在研究DDD，需要一点启发。

我有两个实体

Temple（耳机）包含基本信息（名称、描述……），并有 n 个具有技术描述（CAD 图纸、尺寸……）的变体

我的第一印象是： Temple形成TempleVariant一个聚合体——它们属于一起：它们看起来非常紧密耦合

但后来我读到聚合根之外的任何内容都不允许引用另一个聚合内的实体。但实际上不是Temple被外部实体引用TempleVariants，而是.

这是否意味着在（DDD）现实中Temple，不同的聚合似乎只是一个聚合？TempleVariant

但是，如果我删除Temple呢？正如我所说TempleVariant， s 也必须删除。但这将违反规则“一个聚合更改 - 一个事务”（或它所谓的:)），因为我的“感觉”是我必须在一个事务中删除它们......

所以我的问题是：

华拉巴

score 4 · Accepted Answer

领域模型中的每个类都应该映射您从领域专家那里学习的通用语言。顺便说一句，这看起来是一个非常有趣的领域。

对我来说，有两条不同的路径可以解决您的担忧。

您应该记住，聚合是确保业务不变性所必需的。也就是说：他们收到改变状态的命令，他们有责任避免无效操作（通过适当的异常）。他们通常是实体，因为他们拥有一个身份。

TempleVariants 作为值对象

如果（且仅当）TempleVariant 的实例需要处理业务规则，它们应该是聚合的一部分。也就是说，Temple包含它们。
但是它们应该是不可变的对象：只有它们Temple才能接收改变其状态的命令（总是作为一个整体）。

在这种情况下，当您删除一个 Temple 时，所有连接的 TempleVariants 都会消失。尽管如此，在我开发的大多数 DDD 应用程序中，没有实体被删除：它们只是被存档。但我习惯于金融应用程序和域，可能是在您的域中删除寺庙是正确的做法。

TempleVariants 作为 DTO

如果没有任何命令Temple需要TempleVariant确保业务规则，则该字母可能只是有用的描述性数据，可以使用映射数据库模式的适当 DTO 来处理。在这种情况下，我将定义一个基础设施服务，它返回指定的所有变体Temple。

在这种情况下，您可以在 DTO 中公开相关的共享标识符，Temple但这不是必需的。

有关聚合设计的更多信息，我强烈建议您阅读Vernon 关于聚合设计的文章。

score 0 · Accepted Answer

违反规则和 MikeSW 关于“现实世界”中行为的问题让我重新思考了我的方法。在与领域专家交谈后，我意识到我的方法与 domain 不匹配，因此违反了 ddd。我目前正在重新设计我的模型。

@Question：如果我将TempleVariants 留在Temple模型中，我会采用“ identity-relative-to-its-parent ”方法来引用变体（正如 MattDavey 建议的那样）。但设计中更重要的错误仍然存在。

如果基本设计是正确的，我会创建两个单独的聚合根。它会起作用（从我的角度来看），但它会再次涵盖设计错误（至少在我的情况下）。

一般来说，我认为，如果违反了 ddd 规则，最好退后一步，查看实际业务并检查您所拥有的是否与您的域真正匹配。

谢谢您的帮助！