How do I build a query in CQRS based on metadata without violating separation of command and query side

Question

I checked out these posts, but didn't find an appropriate answer:

CQRS: Read model built on demand?

CQRS - The query side

CQRS: business logic on the query side

I got stuck with my architecture based on CQRS. I understand that the query side should have a thin data access layer, but in my project I need to adjust the query based on metadata coming from other domain objects.

In several articles on the internet there is one table per view in the report database. So a SQL command like 'SELECT * FROM Tablename WHERE...' is all you need. This is not suitable here because the columns returned by the query should be customizable (through a column filter).

This should work as follows:

1. Query is invoked by client, containing a filter id for rows (the WHERE part) and another filter id for columns (the SELECT part).
2. The QueryHandler builds an SQL-query based on information extracted from a domain service based on the ids of the two filters
3. Query is executed against the database and the result is returned to the client

What I'm struggling with is the dependency on the domain service in step 2. For me it feels as this shouldn't be, due to separation between query and command side.

Is this an acceptable way to deal with this problem or is there another approach that separates the two sides?

Answer 1

I think Dennis's answer that's given in your third linked question probably says it best - reporting can be a different bounded context from the rest of your domain. If you can argue that your stored filters are separate from your primary domain, then you're still maintaining the separation on that primary domain.

That your read-side has some logic in it isn't a problem. In this case you're not changing the meaning of the data you're returning. You've not got business logic for your primary domain hardcoded in it. The logic you have is part of a different bounded context that you're not necessarily modelling with CQRS (and even the greatest proponents of CQRS will tell you that you shouldn't be using CQRS everywhere).