You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I have some question about the aggregate isolation. I got the idea that in DDD the aggregate is immutable with read-only properties and the only way to change its internal state is via events and corresponding `Apply methods.
In Marten documentation example (https://martendb.io/scenarios/aggregates-events-repositories.html) it is discouraged in favor of decider pattern. The decider pattern removes the "platform specific" code from business logic - collecting the events, publishing messages, etc.
Does it mean that business logic is only implemented in the event handler and tested with the infrastructure in mind - i.e. verifying corresponding data was modified and some events published?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
I have some question about the aggregate isolation. I got the idea that in DDD the aggregate is immutable with read-only properties and the only way to change its internal state is via events and corresponding `Apply methods.
In Marten documentation example (https://martendb.io/scenarios/aggregates-events-repositories.html) it is discouraged in favor of decider pattern. The decider pattern removes the "platform specific" code from business logic - collecting the events, publishing messages, etc.
Does it mean that business logic is only implemented in the event handler and tested with the infrastructure in mind - i.e. verifying corresponding data was modified and some events published?
Thank you for help,
Karel
Beta Was this translation helpful? Give feedback.
All reactions