Generic Repository Pattern in DDD with CQRS, does it make sense?

Question

Something is bothering me about repository pattern

What is the actual purpose of a repository ? I understand it as a part of Domain.Model, something that provides means of executing commands on aggregates and that is it.

Now if you are using a generic base Repository which provides means for CUD you might say that you're domain is not generic so the repository is not generic and I agree but only from one point of view the queries being emitted and not the commands.

I fell that a generic repository eliminates the need for Domain.Repositories at least in the context of DDD mixed with CQRS (I know that I might sound controversial and it's exactly how I fell as well). But if you split your commands from your queries, then you will have WriteRepositories containing only CUD operations. Thus having lots of duplicates all over the place.

Imagine this

CustomerRepository : ICustomerRepository
{
    void Add(CustomerAggregate agg);
    void Update(CustomerAggregate agg);
}


BookRepository : IBookRepository 
{
    void Add(BookAggregate agg);
}


SubscriptionsRepository : ISubscriptionsRepository
{
     void Add(SubscriptionAggregate agg);
     void Update(SubscriptionAggregate agg);
     void Delete(SubscriptionAggregate agg);
}

...... another 5 repos

So does a generic repository makes sense in the context of DDD using CQRS pattern where you have Command.Stack + Query.Stack ?, and if so, does it eliminate the need for Domain.Repositories (command repositories) ?

Answer 1

What is the actual purpose of a repository ?

Chapter 6 of Evans (the blue book) covers the repository pattern in considerable detail. Repositories "provide the illusion of an in memory collection...."

A REPOSITORY lifts a huge burden from the client, which can now talk to a simple, intention-revealing interface, and as for what it needs in terms of the model

They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources.

It's not part of the domain model, and doesn't directly support command execution. Instead, it's an abstraction that separates the code that understands domain behaviors (via the API of the aggregate roots) from the code that understands how perform data lookup and convert between persisted representations and in memory representations.

I understand it as a part of Domain.Model, something that provides means of executing commands on aggregates and that is it.

Not really? The aggregates roots are part of the domain model, as are the factories that know how to assemble them.

But the repositories aren't really part of the domain model; the domain model doesn't use repositories at all; the application layer consumes them, the infrastructure layer provides implementations.

So does a generic repository makes sense in the context of DDD using CQRS pattern

Well, the guy who popularized the CQRS pattern wasn't a big fan of generic repository interfaces.