Quo vadis? (lat. Whither goest thou?)
Last week I attended this year's edition of one of my favourite software craftsmanship-related conferences: DDD Europe. It was a good time, I've met interesting people, attended a few workshops, enjoyed beautiful weather in always welcoming Amsterdam, but ... I couldn't help feeling that there was something important missing.
The progression.
Bummer
It was the progress (in DDD community) missing & it becomes more & more visible each consecutive year. Why so? It's bold statements time.
I've started designing and building software for money about 20 years ago - even before the Blue Book was published. Those days we were (in general) much worse in learning the business needs & requirements. The techniques (introduced later) like EventStorming, User Story Mapping or (more general) various elements of Lean Product Development have made hell-of-a-difference.
But.
IMHO we were far better in designing solutions then. Those solutions may not have been such adequate for the needs (which sounds kinda like a deal-breaker, I know), but they were more explicit, understandable and better organised. In other words: we were technically better in creating something that badly addressed the needs. We used all those hated notations (UMLs, BPMNs - don't get me wrong, I DO HATE them until this very day) which have helped us to develop our abstract thinking & concise forming of the shared conceptual models. DDD has only expanded those previously acquired skills - added to them, not substituted them.
Over-agiled
Do I have anything to back up this seditious statement?
As time flies by, the more & more programmers from my teams have never been exposed to "traditional" methods of design (notations, breakdowns, outlines, HLDs & DDs, etc.) - those sound extremely dated, but they were the Ubiquitous Language(s) of our design processes. All devs know these days (especially neophytes w/o CS degree) is Scrum, UX-driven user stories & the fairy tales about evolutionary design that will spontaneously pop out of thin air. But no-one ever has taught them HOW TO DESIGN (explicitly). They have been over-agilized.
We (the pitiful old-timers) went through outdated, tedious, formal procedures - these were our katas. We've established ways of thinking, learned short-cuts, practiced avoiding ambiguity (otherwise nasty waterfall-thinking clients would rip our assholes open ...).
Too little "design" in DDD
Now, take this year's DDD Europe agenda. Filter out all the semi-random spot fillers (micro-freaking-services, Docker, serverless, mob programming, meshes, event-sourcing, ...) and what remains? Event storming, identifying Bounded Contexts, Business Model Canvas - handy stuff (& very well served too) - but all these topics are about (early) recognising business needs & learning domain knowledge, NOT the actual design & solution modelling (which are supposed to happen next).
When I've encountered DDD for the first time, this was an incredibly revealing experience & I felt like I've learned a lot (to be precise: how to mine domain knowledge I can do something useful with). But this was almost 15 years ago & it seems DDD has barely moved an inch forward. Next generations of programmers have tons of practical, everyday questions that are not addressed by DDD:
- to navigate complexity within the Bounded Context ("depth"), I need to navigate across levels of detail - how to do that? what kind of conceptual constructs to use?
- Bounded Context can get very capacious ("width") - how to "mine" the focal business needs ("areas") that could group more specific concerns?
- how to specify (most effectively) "promises" between decoupled concern areas in a manageable way?
- when mining knowledge on the level of user interaction (e.g. during EventStorming), how to map it on low-level core capabilities ("services", e.g.: conceptual model of taxes or discounts or pricing) and how to identify those first?
- the dynamic aspects of the systems can be incomparably more complex than their statics - what conceptual vehicles can be used to harness & describe this complexity?
Maybe it's just me, but it seems like many of DDD veterans tackle such problems by intuitively applying their "pre-DDD" skills. But in the same time, those skills are not passed through to the newer generations of developers (because they are considered passé), who instead of tackling inherent domain complexity, lean towards topics they feel more comfortable with - usually accidental, technical complexity.
Disclaimer
I want to make myself very clear - my point is not just to be controversial (for the sake of controversy). Or to criticise a decent event, organised by brilliant & positive people. But I can't resist a feeling that the DDD community needs to take two steps back, re-orient & spur itself in an adjusted direction. I am NOT claiming we need more "DDD frameworks" or "formal notations" - but it's the highest time to re-validate our arsenal, ditch things that don't bring value (e.g. vast majority of tactical patterns) & "promote" the most practical, battle-proven heuristics & technically-agnostic conceptual models.
IMHO DDD will either evolve or die - not necessarily by being forgotten but rather being too detached from the factual needs.
