我正在研究在没有事件存储的系统中采用域驱动设计中的（根）聚合概念的可能性。但是，我对两者的了解越多，感觉一个人如果没有另一个就无法存在。
我还没有读完蓝皮书，但是到目前为止，我对根聚合的理解是，它是聚合的“树”，需要在该根聚合中保持一致。聚合只能通过其所属的根聚合进行修改。最后，根基本上可以定义为“使聚合独立并且在这个域中是否可以独立存在？”。
想象一下一个绿色项目，该项目尚不适合设计事件源，但将来可能会从中受益。没有事件存储将消除跟踪在特定时间点影响根聚合的所有域事件的可能性。这些命令将必须突变根聚合。此外，由于没有事件可重播性，读取端将被限制对“根聚合{id}已更新”做出反应。
在没有事件存储的情况下，是否存在任何合理的方法来使（根）聚合概念存在，还是应该坚持“传统”实体建模，直到有必要对事件采购进行投资？
答案 0 :(得分：5)
我相信您会感到困惑。没有根聚合或聚合树之类的东西。
DDD中存在的总体战术模式的主要目的是定义一致性边界，该边界在技术上转换为事务性边界。当您处理单个命令时，一个聚合中的所有内容都可以更改，但仅此而已。
集合可以由几种实体类型组成。但是，只有一种实体类型用作聚合根。聚合根标识是整个聚合的标识。集合内的其他实体将具有其ID（否则，它们不是实体而是值对象），但这些实体不能被修改或直接从集合外部引用，并且一个集合内的所有实体上的所有操作都将进入集合根。 / p>
聚合的最典型示例是Order，其中Order本身（或OrderHead，如果愿意）是根，OrderLine是实体。一个订单可以有多个订单行，但是任何一行上的所有操作都通过根。
聚合模式与事件源之间没有直接和明确的联系。事件源是实施细节。埃里克·埃文斯（Eric Evans）的书甚至没有提到事件源，它有很多汇总的例子。
事件源是保存数据的方法。实际上，事件源与DDD完全无关，尽管格雷格·扬（Greg Young）最初建议使用事件源作为通过存储域事件来保持聚合的方式。
当您具有纯域模型时，从域模型方面看，使用哪种持久性机制并不重要。许多事件源系统根本没有聚合的概念。例如，《纽约时报》 has built是一种基于事件的内容管理系统，没有考虑任何DDD战术模式。另一方面，大多数使用战术DDD模式的系统都不使用事件源，而只使用基于状态的持久性。