DDD - 更新实体的一个小细节而不更新整个聚合根

Question

说我的AggregateRoot是Order -Model。 有一个带有OrderItems （实体）的集合。 我只有一个用于 AggregateRoot (Order) 的存储库，但没有用于 OrderItems。

当客户只想更新一个 OrderItem 上的Remarks字段等小的更改时，我该怎么办？

我目前的理解是客户端通过DTO发送更新。 然后中间件加载整个订单，然后更新单个细节，并将整个订单提交到存储库。

如果我理解正确的话，这是现实生活中的一个好习惯，还是您的处理方式不同？ 对我来说，这听起来性能不佳且维护不友好。

Answer 1

正如 DDD 中的所有内容一样，答案在于域规则。 一切都必须围绕规则而不是围绕数据结构。

警告：下面的例子太简单了！

您必须更改一个订单项目的备注字段，所以请教您一个问题：备注字段更改操作有哪些限制和不变量？ OrderItem 是否有它需要的所有信息？ 如果是，那么在这种情况下 OrderItem 是您的聚合根。

是否某些备注不允许进入订单项，因为它属于某种类型的订单，但其他订单类型允许此备注。 那么 Order 就是你的聚合根。

这为您提供了有关如何处理它的线索，但是因为您的评论加载带有所有 OrderItem 的 Order 只是为了更改一个 OrderItem 备注绝对没有性能。

“很抱歉我创造了‘对象’这个词，因为它让很多人把注意力集中在次要的想法上。 重要的想法是“消息传递””~Alan Kay

还记得我说过 DDD 必须吸引周围规则而不是周围数据结构吗？ 所以，不要考虑数据结构。 对命令、事件（消息）和规则周围的一切进行建模。 使您的持久性存储库为该命令带来适当的聚合根，使用 AR 应用该命令，返回产生更改的域事件，并使用该事件来持久化新系统状态并通知其他服务有关更改。

来自具有应用程序配额的聚合根不变实施的代码示例

class ApplicationService{
    public void registerUser(RegisterUserCommand registerUserCommand){

      var user = new UserEntity(registerUserCommand.userData); //avoid wrong entity state; ctor. fails if some data is incorrect

      RegistrationAggregate agg = aggregatesRepository.Handle(registerUserCommand); //handle is overloaded for every command we need. Use registerUserCommand.tenantId to bring total_active_users and quota from persistence, create RegistrarionAggregate fed with TenantData

      var userRegisteredEvent = agg.registerUser(user); //return domain changes expressed as a event

      persistence.Handle(userRegisteredEvent); //handle is overloaded for every event we need; open transaction, persist  userRegisteredEvent.fromTenant.total_active_users where tenantId, optimistic concurrency could fail if total_active_users has changed since we read it (rollback transaction), persist userRegisteredEvent.user in relationship with tenantId, commit transaction

    eventBus.publish(userRegisteredEvent); //notify external sources for eventual consistency

  }

这允许您将 OrderItemRemarkManagerAggregate 从持久性带入内存，其中仅包含更改备注所需的信息（即订单项 ID、当前备注、订单项状态、属于的订单类型等）； 只需使用它来应用操作并将更改应用到持久性中。

稍后您可能会担心为多个操作重用聚合（当然总是在同一个有界上下文中），甚至根据需要进行重构。