architecture - 如何正确处理事件溯源中的聚合关系？

Question

当拥有某种“复杂”的域模型时，不可避免地会存在相关实体(这就是聚合根的意义)。但我该如何从事件中重建关系呢？在序列化事件中通过其他聚合 ID 进行搜索显然不是一个选择。

我有一个使用这种数据库结构的想法(例如)。它具有仅包含 id 和外键的聚合表，以简化从不同实体检索所有必要事件的过程。这不是违反了ES原则吗？

Answer 1

DDD says that "rich domain model" consists from entities which handles business logic, and we work with them as they model the domain objects

是的，当您使用事件溯源时仍然如此。

So I can imagine i.e. order.addItem(product) method, where OrderItem creating and making relationship with Order and Product.

啊哈，不——这两种方法都不是。如果 Order 和 Product 是不同的聚合，则 order.addItem(product) 不是您将使用的拼写。订单和产品不对产品的状态承担责任。或者，换句话说，我们从不将聚合根嵌套在彼此内部。

根据 DDD 规则，通常的拼写为 order.addItem(product.id)。请注意这一重要区别:更改订单不能更改产品的任何详细信息。

这是要点的一部分:域中的每个状态都有一个负责维护其一致性的权威机构。

注意:拼写 order.addItem(product) 对于模型来说是有意义的，其中 Product 是一个不是聚合根的实体，而是从属于 Order(更准确地说，每个 Product只与一个订单相关联)。

But if Item has many-to-one relationship to Order, shouldn't it contain orderId instead? (Not Order containing list of ItemId). But that would mean it should be Item.AddToOrder(order.Id), which makes not so much sense.

简单的回答是，根据您决定如何对数据建模以及哪些项目负责维护聚合的完整性，您会获得不同的方法拼写。

向后工作 - 聚合的部分动机(而不仅仅是在整个模型周围有一个大的一致性边界)是并发修改模型的不同部分的想法。 OrderItem 是否是与 Order 不同的聚合将部分取决于同时修改两个不同 OrderItem 的重要性。

对于在线购物车之类的情况，这可能不是非常重要。

对于多方尝试同时修改同一订单的设置，例如

OrderItem.create(order.id, product.id)

这也不是没有道理的。

And still, aggregate root contains other aggregates, and OrderItem in that case is aggregate, not aggregate root or value object.

聚合根负责一个聚合。该聚合(从根本上来说就是“状态”)在概念上可以是从属于根的多个实体的当前状态，每个实体管理整体的特定部分。

And if I'm right, aggregate root contains business logic to control inner aggregates, so we still need to build aggregate root which contains other entities in it.

“内部聚合”没有意义——聚合不能嵌套。 实体嵌套，最外面的实体扮演聚合根的角色。

那么，我们如何构建嵌套实体？

让我们退后一步，看看我们通常如何创建单个实体。我们运行一些查询(如 getById)来获取我们之前保存的状态。

Factory {
    Entity fromState(currentState) {
        return new (entity);
    }

    State fromEntity(theEntity) {
        return theEntity.getState();
    }
}

嵌套实体的工作方式相同，下级实体接管部分工作。对于订单来说，它可能看起来像......

Factory {
    Order fromState(currentState) {
        List<OrderItem> items = ...

        for (State.Item itemState : currentState.items()) {
            OrderItem orderItem = OrderItem.from(itemState)
            items.add(orderItem)
        }

        return new Order(items);
    }
}

Order {
    State getState() {
        State currentState = State.EMPTY;

        for(OrderItem orderItem : this.items) {
            currentState = currentState.addItemState(orderItem.getState())

        return currentState
    }
} 

当我们使用事件源时，变化的一点是我们使用事件集合而不是状态。

Factory {
    Order fromEvents(history) {

        // The one tricky bit -- the history we will be looking
        // at is a mix of histories from all of the entities that
        // coordinate the changes to the aggregate, so we may need
        // to untangle that.

        Map<OrderItemId, Events> = itemHistories
        for (Event e : history )
            items.put(e.orderItemId, e)

        List<OrderItem> items = ...

        for (Events events: itemHistories.values) {
            OrderItem orderItem = OrderItem.from(events)
            items.add(orderItem)
        }
        return new Order(items);
    }
}

Order {
    List<Event> getEvents () {
        List<Event> events = new List();

        for(OrderItem orderItem : this.items) {
            events.addAll(orderItem.getEvents())
        }
        return events
    }
}