domain-driven-design - 在 DDD Aggregate 中修改 Aggregate Root 的子实体的逻辑在哪里？

Question

我使用 Microsoft DDD 微服务示例作为我的问题的基线（https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model）。

我了解在聚合中的所有外部修改请求都通过根（在本例中为订单）。假设我想修改 OrderItem 中的单位数，我是否对 Order 进行了名为“ModifyOrderItem”的操作，然后它将检索 OrderItem 并对其进行修改？在“ModifyOrderItem”命令处理程序与操作中应该做什么？

Answer 1

这种思维方式与 DDD 的思维方式相冲突。您应该询问在不破坏系统的情况下更改项目数量需要哪些信息。有两种类型：

1. 拒绝/接受修改的数据。这是说“你不能那样做”或“一切正常。继续”所需的数据。

2. 重新计算新系统状态以保持一致所需的数据。

一旦你记住了所有这些数据；你必须考虑所有权。如果数据只是 OrderItem 的一部分，那么 OrderItem 就是您的聚合。如果您还需要检查/修改不属于 OrderItem 的数据，那么您需要使用 OrderItem 和其余数据（可能是其他实体或值对象）建模（或重用）聚合并使用它聚合以应用操作。