DDD (Domain-Driven Design) is “only” one essential building block that promises evolutionary software, a software that won’t let you down in a few years or after a few thousand lines of code.
That’s it. I could stop here; the title and this short description tell everything. But is this true? Can everybody reading this relate to that? Is it helpful? I don’t think so.
During the last year, I often heard the question “how can I introduce DDD in my company?” – mostly meaning “in my dev team”. It is time to answer this question now.
Misconception number 1: introducing DDD as a goal
Misconception number 2: DDD is a dev thing, and after the devs “fix this” by applying all the patterns, all problems will disappear – and they will live happily ever after …
Let’s imagine a successful company sitting on 1 million lines of code, with many customers, a few teams, eventually working in silos, with frontend and backend development split. Or a younger company with a similar organisation, the only difference being the effort needed to change things. This company has an agile development process (with sprints and “stories” and one Product Owner pro team, etc.), but they observe that every new feature takes longer and longer. A few devs have read about DDD, maybe even read the Blue Book, and convinced one of the backend teams to introduce DDD. The company agrees to let them do it because they hope that everything will be easy, fast, and bug-free afterwards. So everybody is happy 😊
Fast-forward a few months: now we are at the point when the source code owned by that team was restructured nicely, with value types, entities, aggregates. Ok, the REST API is unchanged because the frontend team is already using it and was not involved in the discussion. But the business logic is cleaned up. The names, the language were defined by the devs – DDD is a dev thing, isn’t it? The development process didn’t change either: they get requirements to implement things without including anything built by the frontend team, the part that the customer sees. For this reason, the refinements are not about customer needs but API calls and frameworks – just like before the rework towards DDD.
JIRA 1234: Please add this new flag “withVAT” to the API call generating the invoice (sounds familiar?)
What is new? Frustration: the PO doesn’t know why the devs are asking for more and more details, and the developers don’t understand why the PO doesn’t grasp the meaning of aggregates, value types, etc.
Refinement: “We cannot add it to that API call; the VAT decision belongs to another aggregate! 🤷♀️ “
And what else is new? Maintaining those API routes becomes harder and harder because they do not follow the business structure but are kept as an Anti-Corruption Layer between the frontend and backend (team 😉).
I am sorry if I am disappointing you; it is not my intention. It is the opposite, actually: to save you from this frustration after investing so much energy — and maybe extra hours — to get everything perfect.
What is DDD: a paradigm, a ruleset that helps you to build evolutionary software. Like Mathias Verraes says
“create options to pick a strategy later before you know what that strategy will be” this is what #DDD gives us, what I call “the pieces fall into the right places all the time” @mathiasverraes @virtualDDD #domainDrinkingDialogues
– Krisztina 🇪🇺 (@YellowBrickC), December 21, 2020
This can only be achieved if DDD stops being “dev-stuff” and becomes a common way to discuss features, behaviours, and capabilities.
And why not? DDD means not only aggregates and value types; the essential component is the ubiquitous language used by business people and customers in your domain. And apropos customer: DDD aims to solve the customer’s problems. These need to be known in the teams applying DDD. Why not create a whole team to handle those needs, from the UI (or even the UX) to delivery? (This move would also change the “somehow agile” development process into a real one, based on feedback and experiments instead of a prepared backlog covering the next three months)
We live in a great time: the accumulated knowledge and the evolution of the software industry over the last 25 years give us everything we need to build resilient, sustainable, and maintainable software that won’t “die” slowly if we are careful and happy to learn. What do we need?
- Visual modelling techniques to discuss and learn the business (like Event Storming, Impact Mapping, etc.)
- Crunching and defining stories aiming to solve customer needs, always with the Ubiquitous Language (like User Story Mapping, BDD)
- A paradigm to make decisions based on the Business Domain, not on hopes or wishes (strategic DDD to write code able to support future changes)
- A guide for organising the teams to achieve good teamwork, less cognitive load and a smooth development process (Context Maps from DDD)
- Open feedback culture to create psychological safety
- A set of patterns to organise the code (DDD again)
- A bunch of practices to write the code right: TDD, refactoring, pairing, mob-programming
- Trunk-based development (aka Continuous integration) and continuous delivery to reduce the lead time (the time from the idea to the usage, also to the possibility of feedback) and to reduce the MTTR (Mean Time To Recovery)
- Mature 3rd party services to fulfil all the other needs when offering digital products. Now we can focus entirely on our business proposal (AWS/Azure & co, Observability, etc.)
- The readiness and willingness to learn the business we want to improve, along with the corresponding company culture that supports this.
This list is my Silver Bullet. All items on it are essential, and all of them exist. Most of them had a significant value for themselves, but the sum of them? Wow, they give us a real chance in this rapidly changing world with all its competitors running after our slice of cake.