我目前正在深入研究 DDD 并需要一点启发。
我有两个实体
Temple TempleVariant Temple（听筒）包含基本信息（名称，描述，...），并且n 变体具有技术说明< / strong>（CAD绘图，尺寸，......）
我的第一印象是：
Temple和TempleVariant形成汇总 - 他们属于一起：
他们似乎紧密耦合
Temple所有TempleVariant应同样删除 TempleVariant 在没有 Temple的情况下不能存在（至少没有意义）但后来我读到没有任何东西聚合根允许引用另一个聚合内的实体。但实际上外部实体不Temple被引用，但 TempleVariants 。
这是否意味着（DDD）现实Temple和TempleVariant 不同聚合 似乎是一个聚合？
但是，如果我删除Temple怎么办？正如我所说，TempleVariant也必须删除。但那会违反规则“一次聚合 - 改变 - 一次交易”（或者所谓的:)，因为我的“感觉”是我必须在一次交易中删除它们......
LG
warappa
答案 0 :(得分：3)
域模型中的每个类都应该映射您从领域专家那里学到的无处不在的语言。这看起来很有趣，顺便说一句。
对我来说，有两种不同的方法来应对你的担忧。
您应该记住，需要使用聚合来确保业务不变量。 那就是：他们收到改变状态的commands，他们有责任避免无效操作（通过适当的exceptions）。 他们往往是实体，因为他们拥有自己的身份。
TempleVariant作为值对象
如果（且仅当）TempleVariant的实例需要处理业务规则，它们应该是聚合的一部分。也就是说，Temple包含它们
但是它们应该是不可变对象：只有Temple可以接收改变其状态的命令（总是作为一个整体）。
在这种情况下，当您删除Temple时，所有连接的TempleVariants都会消失。尽管如此，在我开发的大多数DDD应用程序中，没有实体被删除：它们只是存档的。但我已经习惯了财务应用程序和域名，可能是你域中删除寺庙是正确的事情。
TempleVariant作为DTO
如果Temple中的任何命令都不需要任何TempleVariant来确保业务规则，那么这封信可能只是有用的描述性数据，可以通过映射数据库架构的正确DTO来处理。在这种情况下，我将定义一个基础结构服务，它返回指定Temple的所有变体。
在这种情况下，您可以在DTO中公开相关Temple的{{3}}，但这不是必需的。
有关聚合设计的更多信息，我强烈建议您阅读shared identifier。
答案 1 :(得分：0)
违反规则和MikeSW关于“现实世界”行为的问题使我重新思考了我的方法。在与域专家讨论后，我意识到我的方法与域不匹配，因此违反了ddd。我正在重新设计我的模型。
@Question：
如果我将TempleVariant s留在Temple模型中，我会选择使用“身份相对于其父”的方法来提供参考的可能性变种（如MattDavey所建议）。 但设计中更重要的错误仍然存在。
如果基本设计是正确的，我会同时制作单独的聚合根。它会起作用（从我的角度来看）但再次它会覆盖设计错误（至少在我的情况下）。
一般，我认为，如果违反了ddd规则，退后一步，审核实际的业务和检查你所拥有的东西真正匹配你的域 - 或不。
感谢您的帮助！