我正在研究在没有事件存储的系统中采用域驱动设计中的(根)聚合概念的可能性。然而，我对这两者发现的越多，就越觉得一个没有另一个就不可能存在。
我还没有读完蓝皮书，但到目前为止我对根聚合的理解是，它是一个需要在根聚合内保持一致的聚合“树”。一个聚合只能通过它所属的根聚合进行修改。最后，根基本上可以定义为“让这个聚合独立是否有意义并且它可以在这个域中单独存在吗？”。
想象一个尚未开发的项目，在该项目中设计事件溯源还没有意义，但将来可能会从中受益。缺少事件存储将消除跟踪在特定时间点形成根聚合的所有域事件的可能性。这些命令必须改变根聚合。此外，读取端将仅限于对“根聚合 {id} 已更新”使用react，因为没有事件可重播性。
在没有事件存储的情况下，(根)聚合的概念是否有任何合理的方式存在，或者应该坚持“传统”实体建模，直到对事件溯源进行投资才有意义？
最佳答案
我相信你在混淆事情。没有根聚合或聚合树之类的东西。
DDD 中聚合战术模式存在的主要目的是定义一致性边界，这在技术上转化为事务边界。当您处理单个命令时，一个聚合中的所有内容都可以更改，但不能再更改了。
一个聚合可以由多个实体类型组成。但是，只有一种实体类型用作聚合根。聚合根 ID 是整个聚合的标识。聚合内的其他实体将拥有它们的 id(否则这些实体不是实体而是值对象)，但这些实体不能直接从聚合外部修改或引用，并且对一个聚合内所有实体的所有操作都将访问聚合根。
聚合最典型的例子是 Order , 其中 Order本身(或 OrderHead 如果你愿意)是根和 OrderLine是实体。一个订单可以有多个订单行，但任何一行上的所有操作都通过根进行。
聚合模式和事件溯源之间没有直接和明确的联系。事件溯源是实现细节。 Eric Evans 的书甚至没有提到事件溯源，它有很多聚合的例子。
事件溯源是一种持久化数据的方式。事实上，事件溯源与 DDD 完全无关，尽管 Greg Young 最初提出使用事件溯源作为通过存储领域事件来持久化聚合的方式。
当您拥有纯域模型时，从域模型方面来看，您使用什么持久性机制并不重要。许多事件源系统根本没有聚合的概念。例如，《纽约时报》has built一个基于事件的内容管理系统，没有考虑任何 DDD 战术模式。另一方面，大多数使用战术 DDD 模式的系统不使用事件溯源，而仅使用基于状态的持久性。
关于domain-driven-design - 我应该在没有事件存储的系统中避免聚合 (DDD) 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56978826/