Search code examples
c#domain-driven-design

DDD practice: Should I create a repository for value objects


I have been struggling to understand DDD. Here is a scenario that boggles me. Say we have the entity Fund which has value object allocation/holdings and historical prices. What if a service only wants allocations of a particular fund? Should we return a list of allocation objects or return a Fund entity that contains a list of allocations? If we resort to the first approach, we need to create an Allocation Repository. The second approach seems a bit weird, since the entity is being modified to return only certain value objects to the service. Without much knowledge about the entity, shouldn't the service have all fund fields accessible to it?

My description might not be accurate. Please let me know if I need to clarify my post.

class Fund
{
   int fundId;
   List<Allocation> allocations;
   List<Holding> holdings;
}
class Allocation
{
   string type;
   string percentage;
}

Solution

  • There is multiple variations of repository implementations but I would not mind returning a list of Allocation IF, and ONLY IF, Allocation is never managed on it's own.

    In other words, if you will, at some point, want to get information about an Allocation, no matter which Fund it belongs to, then you will need a repository for Allocations, and if you are making such a repository, then you should have a method like getAllocationsbyFundId(int id) or somethign similar. If it doesn't make sense to look at Allocations on their own without knowning which Fund it is from, then Allocations are really a part of Fund and it would make complete sense to have a method on your Fund repository to return the Allocations of a specific Fund.

    If you, however, end up with a GetAllAllocation() method on your Fund repository, then you have slipped out of a clean pattern.