DDD entity relationship modeling

Question

I have some doubts about entity relationship modeling. For example I have User entity, each user can have a limited number of Task objects. Task is just a simple Value Object. Here all is clear, since user can interact (open, close, change) tasks through User entity that acts as aggregate root.

Now I need to introduce another entity Manager, a manager should have access to all the tasks regardless of who owns them. He can also create tasks and pass the ownership to some user. And I'm a bit lost here how should I model this?

Should I make Task a separate entity/aggregate and keep OwnerId as a reference to a User? I would appreciate some ideas that could guide me in the right direction.

Answer 1

The question you should ask are

1. can a task be referenced from someone else other than its creator (answer appears to be yes now)

2. can a User or manager have an unbounded set of tasks associated?

3. can a task be reassigned to different users?

If these 3 (or other that now I don't have on the tip of my fingers) question have a positive answer, than you domain concept is an aggregate

In your case, your Task concept has all the requirements to be handled as an entity, and the entity as an aggregate.

Why entity?

Tasks, after all, have their own id. You can edit the description of a taks from "Zwip under the carpet" to "Swipe under the carpet" because of a typo, but this doesn't change what you're about to do, and this fits with definition of Entity.

Why Aggregate?

Then it's clear that the above questions have a "yes" as an answer, they can be managed from users or managers, there is no such limit like "a user has around 3 tasks for the entire life[see note]" and this means that you have to change the task status in a separate transaction boundary and fetch them by their gobal id. You don't want to load all the tasks beloning to a certain user, I bet

...but the beauty of DDD approach is that nobody can know this better than the guy/girl who knows how things work in the company that is building this software

[note] notice that the dscrimitator here is not how many tasks the user is currently doing, but all created the tasks associated with all created the users

Answer 2

I have a task management app and I model Task as an aggregate. User is another aggregate.

I model every relationship with a user id reference in Task. For example I see you have ownership and creation. Then I should have in Task entity:

• CreatedBy: the id of the user who created the task.
• OwnedBy: the id of the user who is the task owner.

I have also the concept of assignee, so I have:

• AssignedTo: the id of the user who has to perform the task.

Regarding to Manager, I see it as a role more than a user. A user with the manager role could create tasks, change their owners, etc.

It all depends on your business rules but that's the idea.