First rule of DDD is: let’s not talk about DDD
DDD jargon is a domain expert repellent! Let’s not talk about DDD, but instead, start engaging domain experts in doing DDD workshops!
Let me share a short story. It happened a long time ago when I was a junior developer at a bank. I had the opportunity to meet one of our business sponsors. I had built a rate curve server for his trading activity. Throughout the discussion, I mentioned that I had used Value Object for thread safety. The look on his face was frightening. It taught me never to mention this kind of technical detail with domain experts again.
Let’s not talk about DDD, let’s DO DDD instead!
How to DO DDD?
DDD promises a lot: better software, a more sustainable pace, and continuous refactoring breakthroughs…
But how do we get started in practice? Here are 2 posts I wrote on the topic:
- Organization refactoring: Event Storming and DDD injection
- How to use Event Storming to introduce Domain-Driven Design
The main idea is to run workshops like Example Mapping, Event Storming and others…
Is facilitation a new aspect of the developer job?
With complex domains, domain experts’ collaboration is mandatory for good software. Having them in workshops is the most effective way to collaborate.
To build better systems, we’ll need to master these collaboration techniques!
That’s a big step away from the traditional developer stereotype. It is not a surprise: DDD has always been about collaboration!
Example Mapping is straightforward. Reading the description should be enough to master it. Event Storming is a bit more involved, but still not rocket science. You can start with my detailed guide about how to get started with Event Storming.
Leave a comment