I've got a design problem, and I figure it's not something totally uncommon so there must be some good practices out there.
I have 2 domain entities: Process and Task. A Process is essentially a list of Tasks.
The functionality of a Process is to know what kinds of tasks it consists of (Task instances are created using a Factory when process enters 'Started' status), and to evaluate it's status based on the status of included Tasks.
A Task has a lot of functionality, but what the Process actually only needs from it is it's status, so I figured I should apply ISP here. For that purpose I created an interface TaskStatus, which is implemented in the base abstract Task class, and the Process holds a collection of TaskStatus objects.
Does it make sense up to this point?
Now the problem is that a different component, let's call it TaskProcessor, gets the list of Tasks from a Process, and needs a different kind of access to the Task objects.
How do I solve this? One way I figured out that would let me keep ISP is to move the list of Tasks out of the Process, into a global singleton TaskRepository. Both Process and TaskProcessor could query TaskRepository to get what they need without being dependent on any functionality they don't need.
I don't particularly like this solution because of 3 things: 1. Generally I think that the less global singletons the better 2. It moves the responsibility of holding a list of Tasks out of the Process, which might be a good thing from a SRP perspective, but I do believe that it actually belongs in the Process from a DDD perspective. 3. That's quite a lot of added complexity compared to just changing the type of the Task list in Process and being done with it.