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...


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.

closed as unclear what you're asking by Ixrec, Robert Harvey, Bart van Ingen Schenau, user22815, GlenH7 Jan 26 '16 at 19:41

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Excuse my ignorance but who are Vernon and Millet ? – Mathematics Jan 25 '16 at 12:53
  • @PleaseTeach Added a couple of links. These two are authors of good books on DDD. – Pavel Voronin Jan 25 '16 at 13:07
  • I need to design same sort of adhoc reporting using EF and DDD but only way I can think of is to create a domain service then some sort of filters parameter and include results based on filters, but I am far far away from implementing it, it just gets heavily complex and there is almost no help out there DDD or N-tier – Mathematics Jan 25 '16 at 13:20
  • 1
    DDD is not a software development methodology. It has nothing to say about implementation (i.e. writing code), unless you were actually asking something else. – Robert Harvey Jan 25 '16 at 15:32
  • 1
    @RobertHarvey Thoug UL and cooperation with Domain Experts are emphasized, I cannot completely agree with you. Tactical patterns are also of great importance. First, they have an effect on nonfunctional requirements, and, second (most important), you cannot 'sell' DDD to your teammates, if you cannot give them answers about how to implement something in code. Otherwise everything sounds for them too theoretical and looks good only in ideal world described in books. – Pavel Voronin Jan 25 '16 at 16:18

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.