Finders are they waiting for next evolution step?

[Maciej Hadam]

While analyzing ddd-sqrs-sample code I came into the conclusion than
example finder classes could be easily refactored into the 'ala
command style':
- Command into Criteria
- CommandHandler(with method handle) into Finder(with method find)
(eg. ProductFinder with method findProducts(ProductSearchCriteria
criteria) will change into the ProductSearchCriteria and
ProductSearchCriteriaFinder with 1 method find(criteria))


In the RunEnvironment we have comment :
//You can add Your own capabilities here: dependency injection,
security, transaction management, logging, profiling, spying, storing
commands, etc

Many of this capabilities are also capable for the query part of CQRS
(eg. security, spying, logging).

Staying with current finder solution we cannot easily decorate the
query executions . Of course you can always use AOP but it's not as
elegant as Decorator pattern.

I'm waiting for any comments.

[Sławomir Sobótka]

Yes indeed, technically its just about sending a DTOs (commands/query
results) back and forward. We just call them in more sophisticated way
just to reveal an intention.

But generalizing queries to commands can lead to inconvenient code
where each query is coded in separated handler, and common code must
be moved to some "utils" or sth.
In the current style we can have many search methods in one finder,
and those search methods could share common private code.
Ok, thats the only cans I can think about now:P So as You can see they
are just minor "style issues".
If not having AOP by hand I would probably implement read stack just
like You have mentioned (maybe introducing second gate -
"QueryGate")...