Domain Modelling: Neither an Entity nor a Value Object

Question

In DDD, the domain model consists of entities and value objects, but what do we do when we need something in the model which is neither of these?

For example, I have introduced the following ScheduledItems<T> implementation in order to encapsulate scheduling specifics:

public class ScheduledItems<T>
{
    private SortedDictionary<DateTime, T> scheduledItems;

    public ScheduledItems()
    {
        scheduledItems = new SortedDictionary<DateTime, T>();
    }

    public void ScheduleItem(DateTime scheduledDate, T item)
    {
        scheduledItems.Add(scheduledDate, item);
    }

    public void RemoveItem(T item)
    {
        scheduledItems
            .Where(x => x.Value.Equals(item))
            .Select(x => x.Key)
            .ToList()
            .ForEach(k => scheduledItems.Remove(k));
    }
}

This class will be used by a couple of entities for scheduling purposes.

At this point, this is neither an Entity (it has no identity) nor a Value Object (it is not immutable).

One solution is to turn it into a Value Object by making it immutable ('adding' or 'removing' items would return a new instance of ScheduledItems).

But is this really necessary for something which is not really associated to the domain? This class could be just like any other .NET collection.

handle it as an infrastructure aspect (like logging or security), when scheduling is not part of your domain. — Jehof, Nov 06 '14 at 06:54
@Jehof: This in not an infrastructure concern at all. It is purely a `SortedDictionary` wrapper which is used by domain entities. — Dave New, Nov 06 '14 at 11:33
In my experience, sometimes a use-case looks like a component in the domain model, but the definition cannot fit into any building block of DDD. Maybe it's a use-case. — Abbas Amiri, May 19 '21 at 12:40

score 0 · Answer 1 · answered Nov 06 '14 at 21:19

0

That class looks like a repository for ScheduledItems. So ScheduledItem is the Entity and ScheduledItems is the the Repository with Add(), Remove() methods.

answered Nov 06 '14 at 21:19

Tomas Dermisek

778
1
8
14

It is not a repository, nor is `ScheduledItem` an entity. An entity would use this class just like it could use a `List` or a `Dictionary`. This is in fact a wrapper for `SortedDictionary`. – Dave New Nov 10 '14 at 06:23

score 0 · Answer 2 · answered Nov 18 '14 at 13:27

I guess it depends on why the items are sorted.

If they need to be sorted because of certain business rules then this should be part of your domain.

If they need to be sorted to be properly shown in the UI, then this most likely is just a bit of view logic that should not be part of the domain.

If none of the above, I would consider this a collection-like helper class that could be in a part of the infrastructure layer that could be used across the other layers.

Domain Modelling: Neither an Entity nor a Value Object

2 Answers2