Question

I could use some help understanding my domain model a bit and making sure I am approaching the design correctly.

I have an aggregate root called Department. The Department object has several child value types that help define the business notion of a ‘department.’ In my UI users can list, create, edit and delete Department objects.

I have another aggregate root called Project. A Project has several child value types but also has a relationship to a Department in that each Project is ‘owned’ by a department. Projects can be created, edited, deleted, etc. and doing so has no impact on the department whereas removing a Department also removes any projects it owns.

My UI will display a list of Projects based on the departments the current user is authorized to access. They may be able to access more than one department. When displayed as both a list item as well as in detail, I need to show the Department logo with the Project.

My first thought was the Project was an aggregate root with a simple DepartmentID property that could be used to ‘lookup’ the Department. But now I’m starting to think that I really only have one aggregate root: Department.

What do you think?

UPDATE

I don’t know if it is key to the discussion or changes anything but the following thought occurred to me after reading the first couple of answers.

Department appears to have two contexts:

1. As a stand-alone entity that
   supports modification.
2. As a child of a Project in which
   case is contains read-only data and
   no behavior.

This makes me think that I should have two ‘objects’ in my model, an aggregate root for case #1 and a value type for case #2. Am I on the right track?

Answer 1

Since the Project can’t exist without a Department it’s probably not an Aggregate Root. From your description it sounds like you only have one AR – the Department, which you use to manage the projects inside it.

If your behavior is mostly CRUD, i would not recommend building a full blown domain model for it since there are probably simpler approaches you can take.

UPDATE
As you mention, you might have 2 bounded contexts here. One where the Department is an AR and the Projects are entities of this AR. In this context you would perform operations on your Departments. In a second BC your Project could be the AR and the Departments could be entities or VOs. This would allow you to work directly with projects.

I would also recommend going over this with your domain expert and see if these concepts fit well in your UL, or maybe search for some missing concept that can clarify your model. I would especially look for a concept that might link projects to departments.