When to use a 'Specification' vs when to a 'Query Service'?

[nabeelfarooqui98]

In the Core project we have specifications tied to each domain object. Like getting it by ID or things like "Get Order by ID with Customer Details" where you'd call the Include on customer information.

But I see that when fetching a list the template uses a different approach. A query service. The interface exists in the Use Case project and the implementation is in the infrastructure.

1. Why cant I use a specification for the list too? If I can then how do I decide on which approach to use?
2. How should I handle a use case (hypothetically asking, not sure if it can even happen) which needs to fetch data of 2 different domain objects and for some reason I cant use a navigational property in the specification. Should I use a query service in that case and manually merge data using the dbcontext directly?

Thanks

[ardalis]

Yes the existence of query objects in the template is meant to demonstrate that you're not bound by some rule that says all data access must be through specifications - or even repositories. Instead, especially if you're able to take advantage of Command-Query-Responsibility-Segregation (CQRS), you can use different approaches where appropriate.

1. When you need domain objects because you're enforcing domain rules (usually when you're making changes and mutating state), you probably want to use the Repository pattern possibly along with Specifications.
2. When you just need some simple (read only) data and Repository/Specification can provide it with minimal effort, you can still use these patterns - it may not be worth it to implement a separate query service. Using a projection with the specification (Specification<Source,Destination>) may make sense in these cases, so any mapping is done on the database and extra columns are not returned over the wire).
3. When you need custom readonly data (reports, search results, etc.), don't feel like you must build these queries using specifications (or combinations of specifications) and/or LINQ. Use SQL. Use a stored procedure. Use whatever makes sense and abstract it using its own service. That's what the query services are doing.

Hope that clarifies.

[nabeelfarooqui98]

Thanks. I'll use whatever feels convenient for the job, I was just worried I might be misusing something then later on will regret it lol.

[wtygibbs]

2. When you just need some simple (read only) data and Repository/Specification can provide it with minimal effort, you can still use these patterns - it may not be worth it to implement a separate query service. Using a projection with the specification (Specification<Source,Destination>) may make sense in these cases, so any mapping is done on the database and extra columns are not returned over the wire).

Since it is recommended to store the specifications in the Domain project, would you say this makes it acceptable to keep DTOs in that layer as well to be able to map the projections? To my knowledge, DTOs are generally kept in the Application or API project.