Domain driven design 骨料是否必须具有强一致性？

我在DDD上读到的所有内容都意味着聚合中的状态必须是强一致的

这意味着，如果需要冗余，则只能使用强一致性复制（如2PC、3PC或Paxos）

---

是否允许使用最终一致的复制，如多主或主从复制？如果您确实使用了它们，您所拥有的是DDD术语中的“聚合”吗？这是一件常见的事情吗？

聚合本身需要一致，但是相关聚合最终可以彼此一致。事实上，最终一致性是分布式场景中DDD的常见范例。可以将聚合视为一致性边界。这意味着一个集合的定义必须是一致的，而不是真实的反映

例如，聚合上的行为可以发布域事件，然后将其发布到外部。该事件的带外处理程序最终可以使整个系统进入一致状态。很多时候，最终一致性是完全可以接受的业务约束，特别是因为最终一致性在现实中更为普遍

更多关于这方面的信息，请查看

更新

---

最终，应根据具体情况评估聚合的一致冗余。一些总量将非常适合解决冲突，或许可以采取自然补偿行动。这些类型的冲突将以类似于CQRS类型的冲突的方式解决，其中需要采取补偿措施以使系统进入一致状态。正如在CQR中一样，最终一致性的影响应与领域专家讨论。

您已经描述了DDD聚合的教科书定义，进一步证实了我问题中的介绍。但是，关于聚合的冗余，或者更具体地说，如何处理在不同的数据中心托管冗余副本以满足地理定位需求？跨数据存储的同步等任务应该由存储库或可能的服务来处理（存储库是一种更标准的方法IMHO）-域中的内容只是说明实体是什么以及如何转换的业务规则。