Domain Modeling: Neither Object nor Value Object
In DDD, the domain model is made up of objects and value objects, but what do we do when we need something in a model that is neither of these?
For example, I have introduced the following implementation ScheduledItems<T>
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 multiple entities for planning purposes.
At this point, it is neither Entity (it has no identifier) nor Object Value (it is not immutable).
One solution is to turn it into a Value object by making it immutable (adding or removing items will return a new ScheduledItems instance).
But is it really necessary for something that isn't really domain related? This class can be like any other .NET collection.
source to share
I think it depends on why the items are sorted.
If they need to be sorted due to certain business rules, it must be part of your domain.
If they have to be sorted to display correctly in the UI, then this is most likely just some presentation logic that shouldn't be part of the domain.
If none of the above, I would consider this class-like helper class that could be part of an infrastructure layer that could be used in other layers.
source to share