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

这是聚合的关键。它将协调这个过程。外部代码将无法封装在Aggregate中，因此无法直接在E4上发出命令。而是将命令路由到聚合，聚合将在内部发布和协调流程。

希望有帮助

Answer 2

关于非平凡聚合体的文献非常薄弱。

在处理诸如E4的命令时，从逻辑上讲应该对E2产生一些副作用（事件），最佳实践是什么？

可能要注意的最重要的事情是：因果关系是业务逻辑的一部分，而不是状态的一部分。当我们集成事件时，我们不需要考虑所有事物的整体互连，因为其他事物都记录在其他地方。

当我们根据实体的历史来重构实体时，业务规则不再适用-每个实体状态都是独立地从其自身的事件中派生的。

由于实体都是同一聚合的一部分，因此应将它们的事件一起写入单个事务中的单个持久性存储中。

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

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

事件来源的副作用

2 个答案: