Aggregates are the heart of your system. They hold domain logic and are responsible for emitting events that will
eventually make your data consist...
For further actions, you may consider blocking this person and/or reporting abuse
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
It seems an interesting approach, but I have a question.
It's considered a good practice to keep the setters in your domain model private. In your approach, we're making the events apply themselves, so they need public setters, which might not be ideal.
Imagine we have a property that is set only one time once some event happens. I'll need to expose a setter to that property, which will allow anyone in the code to set it whenever they want.
How do you see this?