DDD: Referencing non aggregate roots

1
votes

I'm trying to improve my design using some DDD concepts. Currently I have 4 simple EF entites as shown in the following image:

enter image description here There are multiple TaskTemplates each of them storing multiple TasksItemTemplates. The TaskItemTemplates contains various information (description, images, default processing times).

Users can create new concrete Tasks based on a TaskTemplate. In the current implementation, this will also create a TaskItem for every TaskItemTemplate, but in the future it might be possible to select one some relevant TasksItemTemplates.

I wonder how to model this requirement in DDD. The reference from TaskItem to TaskTemplateItem is not allowed, because TaskTemplateItem is not an aggregate root. But without this reference it is not possible to get the properties of the TaskTemplateItem. Of course I could just drop the reference and copy all properties from TaskTemplateItem to TaskItem, but actually I like the possibility to update TaskItems by updating the TaskTemplateItems.

Update: Expected behaviour on Task(Item)Template updates

It should be possible to edit TaskTemplate and TaskItemTemplate and e.g. fix Typos in Name or Description. I expect these changes to be reflected in the Task/TaskItem. On the other hand, if the DefaultProcessingTime is modified, this should not change the persisted DueDate of a TaskItem.

In my current Implemenation it is not possible to add/remove TaskItemTemplates to a persisted TaskTemplate, but this would be a nice improvement. How would I implement something likes this? Add another entity TaskTemplateVersion between TaskTemplate and TaskItemTemplate?

Update2: TaskItemTemplateId as ValueObject

After reading Vaughn's slides again, I think with a simple modification, my model is correct according to DDD:

enter image description here

Unfortunately I do not really understand, why this Design is better (is it better?). Okay, there won't be unnecessary db queries for TaskItemTemplates. But on the other side I almost ever need a TaskItemTemplate when working with a TaskItem and therefore everything gets more complicated. I cannot any longer do something like

public string Description
{
  get { return this.taskItemTemplate.Description; }
}
1
domain-driven-design
Btw, don't confuse DDD entities with EF entities. – theDmi
I know in a perfect world there is a difference between DDD and EF. But there are also quite a lot of people trying to apply DDD concepts directly to EF. I'm using DevExpress XAF with Views generated directly based on Entities. Therefore it is not possible to develop a real DDD solution, but I think it is still possible to improve my design with it. – krombi
@krombi can you explain a bit more what you expect to happen to TaskItems when their TaskItemTemplate is modified ? – guillaume31
I updated my question – krombi

1 Answers

1
votes

Based on the properties that you list beneath TaskItem and TaskItemTemplate I'd say that they should be value objects instead of entities. So if there isn't a reason (based on the information in your question there isn't) to make them entities, change them to immutable value objects.

With that solution, you just create a TaskItem from a TaskItemTemplate by copying its data.

Regarding the update scenario that you describe, it see the following solution:

  • TaskItems are created from a specific version of the TaskItemTemplate. Record that version with a TaskItem.
  • The TaskTemplate is responsible for updating its items and keep track of their version.
  • If a template changes, notify all Tasks that are derived from the template if immediate action is required. If you just want to be able to "pull in" the template changes at a later time (instead of acting when the template changes), you just compare the versions.

To make informed decisions, it is very important that you fully understand the pros and cons of immutability. Only then you will see a benefit in modelling things as value objects. One source on the topic that I find very valuable is Eric Lippert's series on immutability.

Also, the book Implementing DDD by Vaughn Vernon explains the concepts of value objects and entities very well.