CODEWITHSUNDEEP
domain-driven-designddd-service
Mike Lenart
Mike Lenart

Reputation: 939

Where does the logic go in DDD Aggregate to modify a child entity of the Aggregate Root?

I am using the Microsoft DDD Microservices example as the baseline of my question (https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model).

I understand that all external requests for modifications within the aggregate goes through the root (in this example the Order). Say I want to modify the # of units in the OrderItem, do I have an operation on Order called "ModifyOrderItem" which will then retrieve the OrderItem and modify it? What should be done in the "ModifyOrderItem" command handler vs. within the operation?

Upvotes: 1

Views: 264

Answers (1)

jlvaquero
jlvaquero

Reputation: 8785

This way of thinking collides with DDD way of thinking. You should ask about what info you need to change # of items without breaking the system. There is two types:

  1. Data for reject/accept the modification. This is the data needed to say "You can not do that" or "Everithing is ok. Go on."

  2. Data needed to recalculate the new system state to keep it consistent.

Once you have in mind all this data; you have to think about ownership. If the data is just part of the OrderItem then the OrderItem is your aggregate here. If there is also data you need to check/modify that does not belong to OrderItem then you need to model (or reuse) an aggregate with the OrderItem and the rest of the data (that could be others entities or value objects) and use this aggregate to apply the operation.

Upvotes: 0

Related Questions