问题
So after much reading I've now come to the realization that complex reporting functions do not belong in your typical Repository and that there needs to be some kind of dedicated "Finder" which returns read only objects to be used in reporting.
What I'm unclear on is where the "Finder" classes, as well as their associated ReadModel classes are supposed to go inside my project? Are the finders like repositories in that you have an interface for the finder inside the infrastructure assembly along with concrete Readmodels?
Where do these classes belong?
回答1:
I usually have a logical query 'layer'. Logical since I do not always need to have it separated into its own assembly (from a .Net/C# perspective). It should not be in your domain since the domain should not be querying IMHO. The domain is concerned with aggregates, entities, value objects and the like. Anything else it needs would need to be fed into the domain objects. The querying bit probably comes into play more on the application service edge.
What I then end up with is my repositories returning only the required full aggregates / entities and a separate IQuery interface implemented on the read side. Typically I have it in a DataAccess assembly. For instance:
public interface IUserQuery
{
bool ContainsEMail(string emailAddress);
int NumberOfAdminisitrators();
DataRow Profile(Guid id);
DataTable FriendRequests(Guid id);
SomeReadModel ForSomethingThatContainsSayAList(DateTime date);
}
You will notice that I use simple types if I can and technology specific data access objects like DataRow, DataTable, never DataSet :) --- although DataSet may be used for composite data but it is somewhat cumbersome.
I try to keep specific read models (DTOs) to a minimum but every once in a while they may be required when dealing with composite data.
来源：https://stackoverflow.com/questions/17140455/ddd-cqrs-confusion-regarding-readmodels-and-the-domain