DDD-在不更新整个聚合根的情况下更新实体上的小细节

作为DDD中的所有内容，答案在于域规则。一切都需要引人入胜的规则而不是数据结构。

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

您必须修改一个订单项的“备注”字段，所以使您产生一个问题：“备注”字段更改操作有哪些限制和条件？是否有OrderItem为此所需的所有信息？如果是，则在这种情况下，OrderItem是您的聚合根。

是否不允许某些备注进入OrderItem，因为它属于某种Order类型，但其他Order类型允许此备注。然后，订单是您的总根。

这为您提供了一个有关如何处理它的线索，但由于您的评论加载具有所有OrderItems的Order只是为了更改一个OrderItem Remark，绝对是无效的。

“对不起，我创造了“对象”一词，因为它使许多人专注于较小的想法。大主意是“消息传递””〜艾伦·凯（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（例如，OrderItem ID，当前备注，OrderItem状态，OrderType所属等）；只需使用它即可应用操作并将更改应用到持久性中。

稍后，您可能会担心为多个操作重用聚合（当然，始终在同一Bounded Context中），甚至根据需要进行重构。