Thanks again for the nice workshop on Axon held yesterday.
Driving back from Amsterdam to Hamburg I had some time thinking about
how to find Aggregates and Aggregate Roots for any domain. I think
this is not easy for someone with the traditional Object-relational
mapping background.
What do you think about Cascading Delete as a hint for finding an
Aggregate Roots:
"The rule of Cascading Delete is sometimes cited as a good way to tell
if you have a group of Entities or VOs that should be an Aggregate –
if the parent, in this case the Order, was deleted all other parts of
that Aggregate below Order would be deleted too. So if it doesn’t make
sense that a parent being deleted would also delete all children, then
you don’t have an Aggregate, you just have a good old fashioned
reference."
(Source: http://thinkddd.com/blog/2009/02/14/aggregates-and-aggregate-roots/
)
I’m glad you enjoyed it. There is nothing as annoying as driving for 10 hours for a workshop if you don’t learn anything from it. I hope I managed to answer some of the questions you had, or better, give you the arguments to persuade your teammates to seriously consider CQRS. If you need any help with that, just let me know.
I think the quote you sent will help find the right aggregates most of the time. And “cascade delete” is probably more intuitive to developers used to ORM. As with any rule-of-thumb, there is always a catch: an aggregate is a little more than that. It is also a transaction boundary. So if the cascade delete MUST be done in the same transaction, then yes, I would put these entities inside the same aggregate.
But if you turn it around: if there is no cascade delete, then you are 100% sure that you are NOT talking about a single aggregate. The proof is easy: you’re not allowed to reference entities other than the aggregate root. If you delete the root, there is no point keeping the other entities around.