In the anemic domain model that I'm using, crudely sketched in an earlier post, I have a handful of "domain cores" (the big balloon thing in the sketch) and a bunch of pluggable "repositories" that get injected into them. But I'm using the term "repository" more broadly than, say, a table in a database. I'm using it as more of a business area that involves some kind of IO. So I have repositories such as:
- CoreDataRepository (the company's core critical data is part of a 3rd party application suite)
- CommonDataRepository (a database of common data that internal applications share)
- HRDataRepository (the database used by the company's 3rd party HR software)
In this design, anything specific to the repository is kept in the repository. The methods only accept/return standard types or domain objects. So the CommonDataRepository would never return a DataSet or a list of an internal entity type, it internally converts anything from the data source into a domain type and returns that. The idea there is to keep any knowledge of the actual I/O strictly inside the repository.
So I guess the first question is, am I off-base here? Is this wrong? Maybe I just need to not use the terminology "repository" in describing these things?
Further down this road, I have another question about how these are organized. Basically: Should repositories be able to internally reference each other?
For example, let's say we're getting the users for a group from the ActiveDirectoryRepository. It will return a List
Currently I have it set up such that, internally, the ActiveDirectoryRepository has an injected dependency on the HRDataRepository and, any time it builds a User object (or list of User objects, etc.) it calls the HRDataRepository. The reasoning for this is, again, to keep knowledge of this in the repositories. Any developer who's writing code to hit that repository just expects back a list of Users, all good and proper. We certainly shouldn't expect every business logic function in the domain to manually hit both repositories and combine the data, should we?
Am I looking at long-term support problems here? Does anybody have any thoughts or insight on this? The IoC of the whole thing works out fine because the repository assemblies (each one is its own project) reference the domain core assemblies into which they'll be injected, so they can see the interfaces for each other inside those assemblies and the IoC container hooks them up just fine.