Let's imagine a simple domain model:
// aggregate root class TaskList( id: Long, name: String ) // aggregate root class Task( id: Long, taskListId: Long, name: String, dueDate: OffsetDateTime, subtasks: List<Subtask>, isDone: Boolean ) // value object class SubTask( name: String, isDone: Boolean )
I consider a
Task an aggregate root since this is the unit of change. It would be pretty uncommon to edit and save the whole
TaskList. That would be even more relevant with multiple users and big task lists. As you can see, the
TaskList doesn't "own" the
Tasks, but a
Task knows to what list it belongs.
So far so good. But what would you do if the user should be able to bring the tasks in an arbitrary order that the application should remember (in a database)? The obvious choice would be to maintain a list of tasks in the
class TaskList( id: Long, name: String, tasks: List<Task> )
However, that would lead to an aggregate root owning another aggregate root what pretty much would ruin the concept of aggregate roots. The best I can come up with is a list of task IDs in the
class TaskList( id: Long, name: String, taskIds: List<Long> )
How would you model that?