views:

67

answers:

1

I've been programming for many years, recently i've been trying to apply some of the ideas from Domain driven design, but I still struggle with deciding on good names for certain parts of a system.

Here's one example;

I have a WCF webservice that returns "Computer" objects. The object is an aggregate root that contains child entities.

The child entities are loaded from two different databases, and from Active Directory.

Right now I have separate Repository classes for each entity "ComputerAssetRepository", "DeploymentRepository", "DirectoryRepository" and so on, then I have a "ComputerRepository" that calls each child repository and returns the result into the "Computer" aggregate root entity.

I should probably only have a single "ComputerRepository" and the other classes are only responsible for data access from the various sources. Since they need common repository functions FindById/Add/Remove/Contains etc I call them repositories.

Is there a better name for these classes?

+1  A: 

I think the right answer hinges on whether or not the ComputerAsset, Deployment, Directory, and other similar child entities are globally accessible aggregates in the same way that Computer is.

Either way, I think they deserve their own repositories and I think they're suitably named for now. A "repository" in the DDD sense simply refers to the traversal mechanism by which you work with existing objects (factories handle the creation of new objects). But if they're not intended to be globally accessible, just make those repositories internal to ComputerRepository.

John Feminella
Thanks for the confirmation.
Andronicus