From the mouths of lots of DDD practitioners, and from Eric himself, we often hear DDD is hard. In my opinion it would be more correct to say DDD is huge. Trying to understand it from scratch, as a whole, is like trying to understand a huge code base as a whole. It’s impressive and discouraging.
But if we split it in small, organized logical components, it becomes easier. Finally we’ll see these components work well together, but before that we’ll grab only what we can, and that’s fine.
After 5 years practicing DDD, I still discover new things every few weeks. That’s ok, I’m not a DDD expert, and still it brings me a lot in my daily work. I’d like to share it in this post, to show you don’t need to know everything about DDD to get a lot from it.
Business first, code after
The first great lesson I learned from DDD was : understand the business. Then we can look for the best technical implementation (if any) to solve their problems.
For me it was a real revelation, it changes the posture I had as a developer. I no longer work to do what someone thinks I have to do. I work with the business, challenge their solution and try to find practical alternatives when I believe they are technically wrong.
In my day to day work it means, talking to domain experts to analyze problems, proposing technical implementation aligned with the domain and easy to modify. I welcome changes as opportunities.
Problem analysis
We can solve lots of problems with software, but it’s hard to figure out which problems are worth fixing. Unless it’s an obvious problem (but was it really a problem in this case?), we have to dig to fix the root problem, not its consequences.
Domain experts usually come to us with solution. The trick is to respectfully challenge them and their solutions. Be a learner, do your best to understand their work and what problem they are trying to solve.
The coffee machine is definitely the place to be to learn things in an informal way.
I often use the 5 whys, and graphical representation to crunch knowledge. Drawing is a fantastical tool to understand complex problems. If you can’t draw it, you can’t understand it. I also organize more formal exchange like Event Storming or Impact Mapping depending on the context.
Whenever it’s possible, I spend some time with the actual users of a system. Usually it’s where we learn the most, seeing how wrong our assumptions were.
Align the technical implementation with the domain
Have you ever try to show your code to a domain expert ? You should. Our code tells a story, it must be understandable by domain experts. The next developer should learn about our domain, just looking at our code.
It’s where we need an Ubiquitous Language, and a clear separation between domain and infrastructure concerns. The Onion Architecture allows that, but it’s not the only way.
Another great way to align our implementation with our domain is Living Documentation. This topic would deserve a whole blog post (or you can read Cyrille’s book). I would just say that it is not only BDD. Living Documentation is more like : how do you generate documentation from your code, not how do you write code from documentation.
Concrete example are the generation of:
– Change log from commits (using GIT)
– API documentation understandable by domain expert (using Sandcastle)
– Workflow description (using static code analysis and tags)
It’s amazing to see the direct impact of these techniques on your codebase. To generate useful stuff from your code, it needs to be clean, and aligned with your domain, in terms of naming and meaning. If the quality is poor, you won’t be able to generate anything understandable. If code and domain are not aligned, you will receive complaints from the domain experts, about how classes/namespaces/modules are badly named. How awesome is that ?
Keep our implementation easy to modify
The business may (will) change, how do we hope to stay aligned if we resist changes? It gets on my nerves when I hear a developer complains because business people “do not know what they want”. Of course they don’t, they can’t forecast the future. Our job is precisely to provide great software, even when requirements and constraints change a lot. I would even argue it’s one of the main difference between high quality software versus cheap software. Good software is resilient to change, bad software is a pain for its developers and users whenever something new happened. What is the point of being “Soft” if we are unable to change?
Our industry knows how to develop software easy to change. We use Unit Testing to provide quick feedback when anything changes in the system. A SOLID design will keep low coupling, which help to change part of the system without breaking everything.
To have a more complete feedback loop, we use DevOps to achieve continuous integration and continuous deployment.
DDD is a lot of good habits
We can’t implement DDD without problem analysis, technical alignment with the domain and a codebase easy to modify. I tried to show that DDD is not something hard. I’m sure you already do, or at least heard about some of the practices I talked about in this post. You don’t need to learn all at once. Be a constant learner, one practice after the other.
Learn about these practices, try to implement them, and you also will get a lot from DDD, in your daily work.
Many thanks to my usual reviewer Brian Gibson.