domain-driven-design - 两个聚合之间的数据重复

两个有界上下文，实现为微服务：

用户管理User使用其、Name等Email托管聚合。

User另一方面，一些sCustomer在会计有界上下文中变为 s。它Customer有自己的工作流程，因此它本身就是一个聚合。它的创建由UserRegistered事件触发（发布/订阅机制）。

为了发送发票，会计需要Customer. 我想知道电子邮件地址（其数据主人是User）是否应该成为聚合的一部分Customer，这将需要同步User.

我倾向于认为更清洁的另一个解决方案是将email address（及其更改）投影到Accounting中的readmodel。因此，聚合是其自身状态（例如支付工作流）的数据主控，但不是.CustomerUser

你怎么看？一般来说，两个聚合之间的数据重复是一件坏事吗？

标签： domain-driven-designcqrs

你怎么看？一般来说，两个聚合之间的数据重复是一件坏事吗？

不。拥有一个“主”副本，由数据的权威拥有，多个从属副本并没有错。当权限完全在您的模型之外时，您的所有副本都可能从属于真正的权限。

数据的复制副本支持自治——即使主节点当前不可用，系统中的其他组件也可以继续使用它们的本地数据副本取得进展。

您确实希望在设计中多加注意——您的能力越接近所需数据的权威，您可能遇到的问题就越少。

（请记住，缓存失效是两个难题之一）。

这方面的一个简化示例可能是发票的已付款状态。您的履行系统可能需要知道发票是否已支付，然后才能发货。您的计费系统拥有已支付发票的决定。两者之间共享了一小部分信息。

但该数据的履行系统副本是次要的——履行系统无权拒绝已付发票。（当然，它可能有权提出异常报告“我们不能满足采购合同的要求”，或其他）。