Ive looked quite a while at others posts in there relativly to aggregates roots. It seem that i don’t understand at all how to define in the right way aggregates roots. I saw answers such as aggregates roots might not be aggregates roots and vice versa. I am a bit confused. The problem is that i have relational model in head but i know that DDD won’t go that way.
Is there a way to define aggregate roots from a relation model ?
Example, if you have a journal that hold journal entries which each hold tasks, problems, and notes
How would you define the aggregates roots ? Is the root a journal ? but that may cause problems if you want to access notes, problems and tasks. So are thoses also aggregates roots which hold reference to journal entries ?
Its something hard to understand and i would like to have some more clarification.
Thanks.
I agree with you that the concept of aggregate roots can be confusing until you get your mind around it. Like most other concepts it gets easier with practice, working it through a few times.
The point of the aggregate is to simplify object traversal for some external obect, in the context of one or more use case(s). You have to start somewhere to satisfy a business requirement, and if you find that you are largely needing a Journal, it’s like that it should in fact be an aggregate root. In most domains that aren’t trivial, you will find it useful to have more than one aggregate root. There is nothing supernatural about the starting object for a use case. You just need to start somewhere.
But again, the point is to simplify object traversal, which simplifies your system. So if Journal is in fact a useful starting point, make all of your calls to Journal first. If a particular use case will wind up needing Tasks, Money, Time or any other useful things, the calling program gets those things by asking Journal, and only Journal. The other objects are part of the Journal aggregate root, for this use case.
For other use cases, it may be more natural and therefore useful for Task to be the starting point, and so you may have a Task aggregate root too, which will likely overlap your Journal aggregate root of use cases. But you ask Task and only Task to satisfy the request (be the only reference that the calling program needs to know about)
Your relational db can and will stay relational of course. But by having your object model evolve to look at requests from an aggregate (starting point object) point of view, your requests from the db will wind up being simpler.
Lay out a use case (or two) and try and work it through. Ask questions within the context of the use case if you like.
HTH,
Berryl