DDD practice: Should I create a repository for value objects

Question

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;
}

Answer 1

To answer the question in the title, no you should not. The repository pattern only works if the items in the repository have identity. If an object has identity then it is an entity not a value object.

Value objects should be all or nothing, e.g. changing one property on a value object replaces the entire thing. Thus a value object is immutable after creation.

That is not to say that a version of a value object internal to the repository cannot have an identity, but you should not let persistence concerns alter your domain.

Based on your description it actually sounds like Allocation is an entity, because it is differentiable and thus has identity.

Assuming that Allocation is an entity, the question I would then be asking is should Allocation be its own aggregate.

Answer 2

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.