我已经完成DDD几年了，在设计聚合时仍然具有挑战性。这是DDD的有趣部分，它让你头晕目眩。我问这个问题，因为我是项目的架构师，我们正在设计模型。当模型与GUI并行发展并与客户一起收集需求时，它是一个迭代。 现在来问题了。我们的情况是，我们正面临一些正在成长为非常大的AR的聚合。我认为我擅长发现Value对象并避免贫血域模型陷阱。但我从来没有遇到过这种情况。 一个例子是我们的系统应代表移动电信天线。天线位于绿色的田野上。但是天线可以有一个带有设备的避难所。天线可以有微波链路，它可以在地面有光纤线路，它可以有无线电元件，它可以有电源。面对它。如果Antenna被终止......所有这些依赖项也会被删除。因为它们是安装的一部分（除了绿色领域:)） 但你明白了。天线模型很复杂......大型AR在并发锁，性能和内存消耗方面都不灵活。
在阅读了Vaughn Vernons关于有效AR设计的非常好的论文http://dddcommunity.org/library/vernon_2011/后，我意识到我们需要开始将我们的大型AR切成碎片。
我的想法是像弗农建议将例如MicrowaveLinks移出到单独的AR（即使它不在现实中）。 MicrowaveLink实体，现在是AR，是Id的参考天线。在MicrowaveLink Entity类中，我们有一个值对象属性，即AntennaId。 我们的用途案例支持这种情况。我们很少将天线和链接列在一起。因此可以通过MicrowaveLinkRepository.ListByAntenna（Guid antennaId）加载MicrowaveLinks
1）您之前是否已完成此AR拆分，您是如何做到的？ 2）你是否设法支持这个AR - ＆gt;通过域约束和DB（我们使用EF 5作为ORM）完整的AR关系？
我的最佳目标是能够跳过Antenna上的Antenna.Microwaves系列。所以Antenna不知道是否链接。链接了解它们所安装的天线。 在MicrowaveLink实体我只希望有一个AntennaId属性，希望有一个DB约束来确保天线存在。
我知道我可以通过T-SQL脚本直接在EF或DB中手动添加种子方法中的FK约束。但EF5 Code First Fluent映射能以某种方式支持这种关系吗？
答案 0 :(得分：1)
通过它的声音你有一个Installation AR。当在另一个中需要AR时，您应该将包含的AR建模为容器中的唯一ID或VO（如果需要）。
你的AR需要有硬边缘。
返回Order / OrderLine示例：）
OrderLine似乎“需要”某个产品，但您不应该将产品实例提供给OrderLine。而是仅将ProductName和ProductId模型化为OrderLine中的VO。现在，您的Order AR有明显的优势。
希望有所帮助。