1

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.

Community
  • 1
Pavel Voronin
  • 1,640
  • 1
  • 18
  • 25
  • 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
  • When you're objectively agreeing on an architectural design decision, it's either something trivial, common or a room with one alpha dog. – JeffO Jan 25 '16 at 16:27
  • "Tactical patterns" sounds like *design* to me, not implementation. Inexperienced software developers [often confuse the two](http://c2.com/cgi/wiki?DesignPatternsConsideredHarmful). I've seen too many software developers try to use software patterns to stitch together a program like a quilt. That's one way to write software, but it's probably not the best way. – Robert Harvey Jan 25 '16 at 16:28
  • @RobertHarvey May be I was not very clear and used wrong word. Changed the title of the question. – Pavel Voronin Jan 25 '16 at 17:20
  • @JeffO What would be you answer to the statement: "I don't like this solution just because it differs from all what we've done before. It is a new approach, how are we going to maintain it? We have 40 modules made the same way, and now you offer something new." – Pavel Voronin Jan 25 '16 at 17:26
  • @voroninp - Being consistent in a project does have a lot of merit, but if the 41st module isn't like the others, consider a better fitting approach and get more people trained. In this case, it sounds like "maintaining the status quo" is the alpha dog in the room. – JeffO Jan 26 '16 at 21:01
  • @JeffO offtopic question: If you realize one day that while being not completely incorrect your prior approach does not comply to best practices and have bad implications. Would you continue the habit for a sake of consistency or will you change it starting from some point, if complete refactoring of the whole system is expensive and thus not feasible? – Pavel Voronin Jan 28 '16 at 06:54
  • It is more than welcomed to implement different DDD bounding context differently. Domain models here, CRUD there, etc. Use whatever is more reasonable at the moment, just keep isolation. [more here](https://software2cents.wordpress.com/2014/04/09/when-ddd-leads-to-crud/) – Dmitry Nogin Jan 30 '16 at 13:56

1 Answers1

1

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.

Dmitry Nogin
  • 450
  • 4
  • 11