Hello, the article is very well written, but I have a doubt, will this disperse the behavior in the aggregation into the order and the event, will it cause the entity to become an anemia model? Is there any other basis for this practice?
You can still implement common business rules in the aggregate and invoke them from your commands/events. The main point is to follow the open/close principal by avoiding to edit the aggregate everytime you add a command/event. I developed this pattern in a project where we had a lot of commands/events. In that case putting everything in the aggregate was not an viable option.
Hello, the article is very well written, but I have a doubt, will this disperse the behavior in the aggregation into the order and the event, will it cause the entity to become an anemia model? Is there any other basis for this practice?
You can still implement common business rules in the aggregate and invoke them from your commands/events. The main point is to follow the open/close principal by avoiding to edit the aggregate everytime you add a command/event. I developed this pattern in a project where we had a lot of commands/events. In that case putting everything in the aggregate was not an viable option.
Thanks to your answer, I probably understand what this practice is all about