DDD、CQRS、事件溯源、聚合、相关聚合和持久性答案

【问题标题】：DDD, CQRS, Event Sourcing, Aggregates, Related Aggregates, and persistenceDDD、CQRS、事件溯源、聚合、相关聚合和持久性
【发布时间】：2020-03-20 21:03:00
【问题描述】：

我刚刚进入 DDD、CQRS 和事件溯源，并且在相关聚合的概念以及发布涉及两者的事件时可以在两者之间共享多少数据时遇到问题。我的问题...我有一个客户聚合，其中包含地址聚合的集合和一个在将地址添加到客户时发布的事件。地址和客户聚合都与电话号码/销售人员和联系人保持关系。

我的理解是我只能通过 id 从另一个聚合中引用聚合。只要我只从客户聚合中引用地址 ID，我是否可以在添加地址时向客户传递更多关于地址的数据，而不仅仅是地址聚合 ID？

我认为我需要额外的数据，因此当我发布事件时，我最终可以将读取端的数据/关系保存到客户地址表中。

【问题讨论】：

标签： domain-driven-design aggregate persistence cqrs

【解决方案1】：

当您发现自己试图访问属于另一个聚合的数据时，您应该仔细检查以确保您的聚合边界符合您的需求。

也就是说，将信息从一个集合复制到另一个集合是合理的。例如，在发货域中，我们可能会将发货地址复制到每个发货中，但我们可能不会在发货实体本身内管理发货地址的生命周期。

因此，我们倾向于关注哪些实体持有权威信息，以及哪些实体使用过时的不可变副本。见 Pat Helland Data on the Outside....

【讨论】：

感谢您的回复和链接。在这种情况下，我相信地址的生命周期是由客户管理的，但由于地址管理自己的联系人/电话号码等。我认为我应该将其分解为自己的聚合。无论如何，当我为读取模型将其持久保存到 SQL 时，我如何将两者联系起来？那是地址表、客户表和两者之间的查找表吗？你能举个例子吗？
有助于回归基础。读模型和写模型/域模型是两个完全不同的东西。读取和/或搜索是在针对任务高度优化的读取模型上完成的。但是写模型是非常基础的。按 id 查找并按 id 列出所有事件大约与您通常需要的一样多（除非您使用快照）。因此，您不会在写入端将一个聚合与另一个聚合“关联”起来，因为这听起来像是一个关系数据模型。
@Codescribler 我不想关联写入模型。现在事件首先被持久化到事件存储中，然后我发布另一个事件以持久化到读取端数据库。我的问题是，一旦数据被持久化到读取端，我如何关联“客户和客户地址”？据我了解，您不能直接查询事件存储。