事件采购中的副作用

Question

假设我有以下关系）：

Aggregate A (contains E1, E2, E4)
 - Entity of type E1
 - Entity of type E2 (contains E3)
   - Sub-entity of type E3
 - Entity of type E4

所有实体都实现以下签​​名：

fun handleCommand(command: Command): List<Event> // returns a list of events that can be applied on itself
fun handleEvent(event: Event): Entity // returns itself with the new event applied

当处理命令E4时，这应该在逻辑上导致E2上的一些副作用（事件），最佳做法是什么？请注意，这不应与sagas混淆，但这是一个一般性问题，关于在处理子实体上的命令时如何生成对父实体产生的副作用。

Answer 1

这是聚合点。它将协调这一进程。外部代码无法直接在E4上发出命令，因为它将封装在Aggregate中。而是将命令路由到聚合，聚合将在内部发布和协调该过程。

希望有所帮助

Answer 2

关于非平凡的聚合，文献相当薄弱。

在处理说E4的命令时，这应该在逻辑上导致E2上的一些副作用（事件），最佳做法是什么？

可能最值得注意的是：因果是业务逻辑的一部分，而不是状态的一部分。当我们整合事件时，我们不需要考虑所有事物的整体互联性，因为其他事情都写在别处。

当我们从历史中重构实体时，业务规则不再适用 - 每个实体状态都是孤立地来自它自己的事件。

因为实体都是同一聚合的一部分，所以它们的事件应该一起写入单个事务中的单个持久存储。

因为实体状态在逻辑上彼此隔离，所以事件的顺序并不特别重要 - 实体行为是并发的。每个实体都应该以“正确”的顺序看到自己的事件，但是实体E4从E2之前或之后的事件中重构并不特别重要。

（单个实体中的事件顺序可能仍然相关。）