这花了一段时间，但我觉得我已经开始对DDD中的聚合有一个很好的了解。保持它们较小（尽可能使用带有值对象的实体），并且在包含多个实体时，请确保它们存在的原因是强制执行一些（事务性）不变式。
关于事物的“删除”或“删除”方面，我有些不满意。想象一下：
主题，带帖子
很长一段时间以来，我都会把'has-a'关系误认为一个聚合，但是...
帖子必须具有线程的要求可以通过线程上的工厂方法强制执行以添加帖子。
然后，可以使用单独的聚合来代替需要它的任何业务规则。例如，如果您正在加载线程列表，那么也必须同时加载每个线程的所有帖子并没有多大意义。
但是如何删除线程呢？删除线程意味着该线程的帖子也应该走。但是，如果强制删除某个帖子，则必须在删除其线程时删除该帖子，这会使它们成为以Thread为聚合根的单个Aggregate。
这只是一个代表性的示例，但是在许多情况下，任何“具有”关系通常都暗示着类似上面的内容。即。如果删除了父级，则该子级将不再存在。
那么，当似乎需要在两个实体之间建立聚合关系的唯一原因是出于删除/删除目的时，有什么建议？
我现在在想什么？
还有其他智慧珠子学会了确保不将“有”关系与根/子实体的总和混淆吗？
答案 0 :(得分：3)
您并没有真正删除线程。您将其设为非活动状态。
还有其他智慧珠子学会了确保不将“有”关系与根/子实体的总和混淆吗？
我要说的最重要的一课是：如果必须立即将两条信息保持彼此一致，则必须将它们存储在一起。换句话说，对即时一致性的需求不仅对您的域模型，而且对您的数据模型都施加约束。
在业务系统中，“必须保持一致”的频率比您预期的要少，因为“必须保持一致”的主要动机是“如果不保持一致，那么企业的成本是多少？”
这里使用的经典示例是订单与库存；我们不需要在地板上保留储备即可接受新订单-“延期交货”是领域中的真实事物，并且比起使所有内容立即保持一致，这通常是更好的经商方式。