What benefit do I get in making an @Aggregate field (ie. List transactions;) an @AggregateMember? I see that these classes can include event/command handlers, but what’s the real power in having these? Is that we can now issue commands to these members where we can isolate the verification logic in these pojos, rather than the aggregate root itself? Essentially they can manage their own state, similar to having another @Aggregate. I’d imagine if our aggregate root had a bunch of these fields, the code in our aggregate root would start to become large. Any thoughts here?
I find the usage of the Aggregate Member to embrace the structure of your domain model.
The definition of an aggregate is:
- A group of associated objects which are considered as one unit with regard to data changes.
- External references are restricted to one member of the aggregate, designated as the Aggregate Root.
- A set of consistency rules applies within the Aggregate’s boundaries.
I’d wager that especially point 1 makes it clear. An Aggregate simply isn’t a single thing from the inside. It consists of a multitude of objects. These objects can in turn be value objects or entities. Furthermore, one of the entities in the aggregate would become the Aggregate Root, as there can only be a single external reference (i.e. the object containing the aggregate identifier).
So using the @AggregateMember annotation allows you to more clearly model the Aggregate structure to reflect your domain model. It is from this idea that you can indeed make statements like “this entity encapsulates some of the logic”, among others.
This is my two cents to the situation. Hope this clarifies things for your @blackcompe!