#47 DDD Series: Get Your Head Around The Domain First
As developers, we often get caught up in the technical aspects of our code - the patterns, frameworks, and architecture - while losing sight of what truly matters: the business domain.
Years ago, I decided to dive into Domain-Driven Design. Everyone in tech was talking about it, and I wanted to understand what the buzz was about. Like with any new topic, the challenge was figuring out where to begin.
I reached out to one of my mentors for advice. He said, "MJ, you need to get your hands on the Blue Book of DDD. Once you read it, everything will click. It is the best resource out there."
"Perfect, this should be straightforward. A couple of months of reading and I will have this DDD thing figured out," I thought to myself.
I grabbed a copy. Now, nine years later, I can say it is worth its weight in gold. But - and there is always a "but" - it took me nine years of hands-on experience and reading other books (like the Red one) to reach the level where I am satisfied (but I am still learning!). Along the way, I have made every mistake: botched projects, misunderstood concepts, and architecture that were way more complex than it needed to be.
It has been an incredible ride, though I had to learn most lessons the hard way - through my own mistakes (and my team's).
Strategic Domain-Driven Design is not rocket science - it is not like quantum physics where you need to completely rewire your brain. However (yes, another "but"!), you do need to push past your comfort zone and break free from thinking purely in technical terms - all those providers, controllers, managers, and handlers.
The real key is understanding the business.
Getting Your Head Around the Domain
Every business has its domain - could be one, could be dozens, could be hundreds - where it operates and generates revenue. Starting at a new company or joining a new project can feel like drinking from a firehose - you are trying to prove your worth while juggling major decisions. It is like being thrown into a tornado of architecture diagrams, documentation, requirements, new team dynamics, and organizational politics. Even seasoned pros can get overwhelmed by this information overload.
With all this chaos, it is tempting to skip getting to know the business domain you are working in. Someone might tell you, "Don't worry, all the requirements are documented - we don't need to spend more time on business analysis."
This is exactly how legacy nightmares begin.
You need to be upfront about needing time to understand the domain and its processes - being new means you won't grasp everything just by reading documentation. You will need to run workshops - prepare for a few days for simpler businesses, possibly weeks (or months) for more complex ones.
Getting buy-in for this can be tough when you are still building trust. Usually, you get one shot at it. That first workshop has to deliver - if it is high-quality, gets people engaged, and sparks meaningful questions, you will have set the stage for future sessions. The key is to convince the others that it is really worth running it.
Running Workshops
So you are ready to kick off your first workshop. Priority number one is setting a clear goal - something concrete you can build on.
Typically, I focus on mapping out the most business-critical process - the one that will be at the heart of the system. Sometimes this process lives entirely in your system, sometimes pieces of it happen elsewhere. Take a process that includes submitting requests to government legal systems - you might have to wait weeks for a response before moving forward internally.
For this kickoff workshop, you want the heavy hitters - decision-makers who can actually approve changes, and domain experts who know the nitty-gritty of different areas (think logistics folks, accountants, sales teams, legal experts). If you are dealing with a legacy system, bring in the developers who have been in the trenches with it - they often understand the business logic better than anyone.
When planning the details:
Group Size - I cap it at ten people. Any more and I can't give everyone the attention they deserve. Smaller groups tend to have better discussions and everyone gets a chance to contribute meaningfully.
Location - While remote can work, I lean toward in-person meetings (even though in general I am a remote-first person). People are generally more engaged face-to-face, and it is easier to read the room. Plus, you can't beat physical whiteboards and sticky notes for collaborative work (I still love you Miro!).
Timing - My sweet spot is three 1.5-hour blocks spread across two days. Often we need more time, but that is fine - I just schedule follow-up sessions. Short, focused sessions beat long, draining ones where people check out mentally.
Now you can start thinking about your approach. There are several proven methods but here are my favorite two:
Event Storming - this technique gets teams exploring complex business domains by mapping out events, commands, policies, actors, read models, external systems, and more. It is particularly effective at spotting domain (you can also call it business) events and tracking how information flows through the system.
Domain Storytelling - a workshop format where you listen to stories about how people and systems work together within their domain, and you visualize these stories with a simple pictographic language, making complex processes surprisingly clear. It is great for discovering edge cases and getting everyone on the same page about how things actually work.
It is also fine to combine both methods. I often start with Domain Storytelling to capture the big picture - it helps business stakeholders visualize how their processes flow at a high level (usually DS is a preferred way of doing it - don’t ask me why), and everyone can easily follow along. Once we have this shared understanding, I switch to Event Storming to dive deeper into specific processes we have identified.
This post is the start of the series related to Domain-Driven Design. In the next week, we will focus on discovering the fitness domain.