Vernon and Millett describe several patterns of getting data for ui (reporting in general) needs.
Though some pros and cons of each approach are discussed, I could not get a robust understanding of which to use when.
Consider ad hoc queries. Vernon calls them Use Case Optimal Query, but does not say too much. Millett just warns about performance vs dry violation tradeoff. Some blogs discuss it as the step towards CQRS.
And all this seems to be more a matter of personal preferences rather than a well-grounded choice. And as soon as subjectivity appears while discussing architectural decisions conflicts occur.
Update I’d add more details, I suppose…
Preface
First, we do not really do DDD. Absolutely. In no way.
We use (sad but true) TransactionScript with AnemicModels.
Yes, we do have complex Domain, where DDD won’t be an overkill.
Now I hear you say: “DDD is about Strategic Patterns!”. I know, they are also not with us. =)
Nonetheless, all patterns are useful. if applied reasonably.
Nobody prohibits making converging steps from both sides. I have already stressed in comments that Tactical Patterns worry team the most, and can bring dividends relatively fast.
The case
In our business rules we extensively use DTOs which contain all data sufficient for performing command processing. However, we use same DTOs for assembling data for UI/Reporting. It introduces very unpleasant coupling. Practice shows that these DTOs are often bended towards UI needs. But it is UI what changes frequently for several iterations. Users understand they’d like to have more data differently structured and organized.
Contrary to UI, Commands are much more stable, and when structure of command needs to change UI gets almost inevitably changed as well.
Thus ‘breathing’ UI ‘shakes’ the layers used by business logic which processes commands. We often find ourselves aligning interfaces and fixing broken tests.
With all said above I found it reasonable to TRY to decouple queries from command processing in absolutely new functionality.
IBlaBlaQuery is the exact implementation of Use Case Optimal Repository Query. Client receives specific view data + data for building commands. It is covered with unit and integration tests. Code works, some teammates like the solution.
Yet exist those who
– a) insist on violated DRY principle,
– b) complain about new unaccustomed design.
You probably ask here: “Why didn’t you discuss this design prior putting it into life?” And that is the place for my question.
They keep pushing on defending DRY, you offer them to face the facts and agree on fragility of design, they declare they don’t see it or it is not such a big problem as a radically new approach. Other developers prefer to stay neutral and do not explicitly express their opinions.
Cannot you give us unequivocal solid arguments? – Then we do not accept and even consider a trial of your design.
After several such iterations you just recall sayings “Practice is the criterion of truth” and “It’s better ask for forgiveness than permission” and voluntary give it a go instantly becoming a jackass. (Can admit I really am, but simply do not notice it.)
That’s why I try to avoid subjectivity and ask for formal objective criteria.
12
Is it possible to just directly query ORM to get UI/Report data? It is usually the most efficient way. If you do need some sophisticated business logic to be involved in reporting because of current big gap between db and required data set – well, you might consider saving some redundant stuff when your command results persist or even run report data preparation commands as a dedicated service. I would say you are never wrong when you have db (the same or dedicated extra one) matching your reporting needs.
The worst thing ever for me personally is mixing command and query logic in the same aggregate, so it is a big deal to be able report by some plain SQL without much DDD stuff involved.