architecture - 如何在 DDD + CQRS + Event Sourcing 方法中处理业务规则？

Question

我试图弄清楚如何使用 CQRS/ES 方法处理复杂的域模型。假设我们有例如订单域实体，处理订单的状态和行为。它有一个 Status 属性，带有用于在状态之间切换的转换规则(实现 State pattern 或任何其他类型的状态机)。根据 DDD 原则，这个逻辑应该在 Order 类(代表 Order 模型)本身中实现，具有 approve()、cancel()、ship 等方法()等

看different public examples在这种架构中，事实证明域实体和聚合根是相同的，它处理状态和行为，甚至处理它自己的事件投影。是不是违反了SRP？

但我的问题更具体:如果我想处理新命令(并应用新事件)，我是否应该从事件流(即从写入模型和写入数据库)重构实体并调用其行为方法(将事件应用于state) 来处理业务规则？或者只是自己处理命令和事件，没有任何写模型实体？

伪代码说明:

class ApproveOrderHandler
{
    private EventStore eventStore

    // ...

    public void handle(ApproveOrder event)
    {
        Order order = this.eventStore.findById(event.getOrderId()); // getting order projection from event store
        order.approve(); // handling business logic
        this.eventStore.save(order.releaseEvents()); // save new events (OrderApproved)
    }
}

class Order extends AbstractAggregate
{
    private Uuid id;

    private DateTime takenAt;

    private OrderStatus status;

    // ...

    public void approve()
    {
        this.status.approve(); // business rules blah blah
        this.Apply(new OrderApproved(this.id)); // applying event
    }

    // ...
}

是不是有点过头了？

我应该如何处理事件溯源中实体之间的关系？如果它们只存在于“读取模型”中，那么在领域实体类中就没有意义了。

编辑:或者我应该将状态快照存储在“读取数据库”中并从中恢复实体以进行操作？但它打破了“不同的读写模型”的想法......

EDIT2:修复了读/写模型错误

Answer 1

TL;DR

But my question is more concrete: if I want to process new command (and apply new event), should I reconstitute entity from event stream (i.e. from write model and write db) and call its behavioral methods (which applies events to state) to handle business rules?

是的。

Or just handle commands and events themselves, without having any write-model entity?

没有。

再一次，带着感觉

命令处理程序位于应用程序组件中；业务模型存在于领域组件中。

保持这些组件分离的动机:使模型更换具有成本效益。领域专家关心的是领域模型，企业在哪里获得胜利。我们不希望编写一次业务模型并使其始终正确——更有可能的是，我们将更多地了解我们希望模型如何工作，从而定期对模型进行改进.因此，用另一个模型替换一个版本的模型不会有太多的拖累——我们希望替换很容易；我们希望做出改变所需的工作量能够反射(reflect)在我们获得的商业值(value)中。

所以我们希望将好东西从“管道”中分离出来。

将所有业务逻辑保留在域组件中会给您带来两个简单的胜利；首先，您不必猜测业务逻辑在哪里——无论用例的细节是简单还是困难，业务逻辑都将在订单中，而不是在其他任何地方。其次，由于业务逻辑不在命令处理程序中，因此您不必担心创建一堆测试替身来满足这些依赖要求——您可以直接针对域模型进行测试。

So, we use handlers to reconstitute entities and calling their business logic methods, NOT to handling business logic itself?

几乎——我们使用 repositories 来重构实体和聚合来处理业务逻辑。命令处理程序的作用是编排；它是 data 模型和 domain 模型之间的粘合剂。