DDD：聚合和删除
DDD: Aggregates and Deletes
这花了一些时间，但我觉得我已经开始对 DDD 中的聚合有了很好的理解。使它们保持较小（尽可能使用具有值对象的实体）并且当包含多个实体时，确保它们存在的原因是强制执行某些（事务性）不变性。
当涉及到事物的删除或删除方面时，我有点未完成。想象一下：
线程，有 Posts
很长一段时间我都将 'has-a' 关系误认为是聚合，但是...
Post 必须有线程的要求可以通过线程上的工厂方法强制执行以添加 Post。
然后代替需要它的任何业务规则，它们可以是单独的聚合。例如，如果您正在加载一个话题列表，那么还必须为每个话题加载所有帖子就没有多大意义。
但是删除一个线程呢？删除线程意味着该线程的 Posts 也应该删除，这是有道理的。但是强制要求在删除线程时必须删除 Post 会导致它们成为以线程为聚合根的单个聚合。
这只是一个有代表性的例子，但在许多情况下，任何 'has-a' 关系通常都暗示着与上述类似的东西。 IE。如果删除父项，子项将不复存在。
那么，对于似乎需要两个实体之间的聚合关系的唯一原因是为了 delete/remove 目的的情况，有什么建议吗？
我现在的想法是什么？
- 你并没有真正删除一个线程。你让它不活跃。
- 当线程处于非活动状态时，您显然不能添加任何新帖子（通过工厂方法强制执行）。通过最终一致性，属于现在非活动线程的所有帖子也将变为非活动状态？
是否学到了任何其他智慧珍珠来确保不混淆 'has-a' 与聚合根/子实体聚合的关系？
You don't really delete a Thread. You make it inactive.
Any other pearls of wisdom learned to ensure not mixing up a 'has-a' relationship with an aggregate root / child entity aggregate?
我想说最重要的教训是：如果两条信息必须立即保持一致，那么它们必须存储在一起 <-- 同一个数据库。换句话说，对即时一致性的需求不仅对您的领域模型施加了约束，而且对您的数据模型施加了约束。
在业务系统中，"have to be consistent" 的出现频率低于您的预期，因为 "have to be" 的主要动机是 "what is the cost to the business if they are not?"
这里使用的经典示例是订单与库存；我们不需要为了接受新订单而在地板上保留可保留的库存——"backorder" 是领域中的真实事物，而且通常是比保持所有内容立即一致更好的开展业务的方式。
这花了一些时间，但我觉得我已经开始对 DDD 中的聚合有了很好的理解。使它们保持较小（尽可能使用具有值对象的实体）并且当包含多个实体时，确保它们存在的原因是强制执行某些（事务性）不变性。
当涉及到事物的删除或删除方面时，我有点未完成。想象一下：
线程，有 Posts
很长一段时间我都将 'has-a' 关系误认为是聚合，但是...
Post 必须有线程的要求可以通过线程上的工厂方法强制执行以添加 Post。
然后代替需要它的任何业务规则，它们可以是单独的聚合。例如，如果您正在加载一个话题列表，那么还必须为每个话题加载所有帖子就没有多大意义。
但是删除一个线程呢？删除线程意味着该线程的 Posts 也应该删除，这是有道理的。但是强制要求在删除线程时必须删除 Post 会导致它们成为以线程为聚合根的单个聚合。
这只是一个有代表性的例子，但在许多情况下，任何 'has-a' 关系通常都暗示着与上述类似的东西。 IE。如果删除父项，子项将不复存在。
那么，对于似乎需要两个实体之间的聚合关系的唯一原因是为了 delete/remove 目的的情况，有什么建议吗？
我现在的想法是什么？
- 你并没有真正删除一个线程。你让它不活跃。
- 当线程处于非活动状态时，您显然不能添加任何新帖子（通过工厂方法强制执行）。通过最终一致性，属于现在非活动线程的所有帖子也将变为非活动状态？
是否学到了任何其他智慧珍珠来确保不混淆 'has-a' 与聚合根/子实体聚合的关系？
You don't really delete a Thread. You make it inactive.
Any other pearls of wisdom learned to ensure not mixing up a 'has-a' relationship with an aggregate root / child entity aggregate?
我想说最重要的教训是：如果两条信息必须立即保持一致，那么它们必须存储在一起 <-- 同一个数据库。换句话说，对即时一致性的需求不仅对您的领域模型施加了约束，而且对您的数据模型施加了约束。
在业务系统中，"have to be consistent" 的出现频率低于您的预期，因为 "have to be" 的主要动机是 "what is the cost to the business if they are not?"
这里使用的经典示例是订单与库存；我们不需要为了接受新订单而在地板上保留可保留的库存——"backorder" 是领域中的真实事物，而且通常是比保持所有内容立即一致更好的开展业务的方式。