aggregate root design and size

Question

I know there are a million questions like this. I'm sorry. I think mine is different but it may not seems so. I am new to DDD and trying to get a grip. Part of my domain is like this. Location 1-* Field Field 1-* Event Field 1-* Task Task - Employee

now it would seem that the AR is the Location. and if I wanted to get a particular task I would have to traverse down to the task through the collection of fields in to the collection of tasks.

This sounds pretty laborious since I am dealing with tasks and events a lot and almost never with a location per say. The location serves to segregate a group of fields and their corresponding entities. So in the ui, I may pick a location and get a list of fields. I then would pick a field. From there I might edit one of it's tasks. So I have a collection of tasks and I pick one so I have the Id of the task. I then need to traverse up to location and get his Id so I can get the AR and traverse back down to the task. Or rather I would be keeping the Id of the AR around so that I could get it. So should I be keeping the Id of the Field around too? so what I return to the server would be the AR.Id, the Field.Id and the Task.Id that I want to look at?

Secondly, an employee of course could not be an Entity it would most likely be an AR. Is it ok for an Entity on an AR to have a collection of ARs?

So perhaps the way it should be structured is like this?

public class Location  // is an aggregate Root
{
    public IEnumerable<Field> Fields {get;set;} //in real code encapsulated. not here for brevity
}
public class Field  // is an Aggregate Root
{
    public Location Location {get;set;}  //reference to AR
    public IEnumerable<Task> Tasks {get;set;}
    public IEnumerable<Events> Events {get;set;}
}
public class Task // is an Aggregate Root
{
    public Field Field {get;set;}  // reference to AR
    public IEnumerable<Employee> Employees {get;set;}
    public TaskType TaskType {get;set;}  // probably Value Object
    public IEnumerable<Equipment> Equipment {get;set;}  // maybe Entity or AR
} 

This makes it much easier to deal with the objects that are modified the most and to traverse their relationships, but it also feels sort of like plain old OOP and that AR doesn't really mean anything.

Again I'm new to DDD and don't have anyone to run this by for a sanity check. Please help me get a grip on how these boundaries are drawn, and if it is the first way, is there an easier way to handle dealing with the Entities then carrying around the AR.id, ParentParent.Id, ParentId and finally the object of interest Entity.Id

Thanks for any thoughts R

Answer 1

Ok, upon some more googling I found this great series of articles.

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf

to get to part 2 and so on just change the last didgit in the url.

Here I discovered that, much like Yves points out, I was misunderstanding the purpose of Aggregates and Aggregate Roots. Turns out they are about maintaining consistency between related entities rather then just bundling up a bunch of entities that have relations to each other.

So if a Field could only have 3 Tasks on any given day, then a Field would be a good candidate for an AR since if you were just adding Tasks willy nilly you could easily create an invalid state in the system, where as if you had to add a Task via a method on Field, then it could easily be checked whether that is acceptable.

Further one wants to avoid giant aggregate roots because they take a lot of resources to load, and can cause concurrency problems. etc etc read the articles they address my above question beautifully