Why did I have a Domain-Driven Design (DDD) Foundations training? I’ve always been a big supporter of continuous learning and, as a social scientist, I know how easily we get trapped in cognitive bias and heuristics. That’s why I’m convinced that it’s crucial to continuously challenge your own perspectives, opinions, and judgments. And that’s how I ended up at the DDD training.
“Once we start judging, we stop learning.”
For me, Domain-Driven Design (DDD) is all about a way – or method, technique, approach, whatsoever – to create a shared sense of reality and deal with socio-technical complexity. Not a goal in itself – although I see that happening very often, as with every other ‘new kid on the block’ – but a means to an end. It’s about getting somewhere together, about collaborative modeling together with business experts, stakeholders, UXers, testers, and developers. Breaking the silos!
So, I was quite excited to join a 2-day training from Kenny Baas-Schwegler. My personal goals were:
- Gain more and new knowledge on DDD in general, and specifically on tactical patterns.
- Challenge my current knowledge, biases, and thinking patterns that I might be stuck in.
Day 1 – Learning Domain-Driven Design (DDD) basics
Introduction to Domain-Driven Design
On a very early Wednesday morning, I was heading to Xebia HQ in Hilversum, where the training course would take place. Started with some coffee, chit-chat, and a little bit of waking up. We were with 8 people. Pretty soon, it got clear to me that this was a diverse group of people. Different backgrounds, interests, and nationalities. “This will be fun!”, was my first thought.
The training room didn’t look like your typical classroom. I saw some papers with drawings on the wall, and a huge suitcase with stickies, markers, sharpies – and everything else my 8-year old self would have gone crazy about.
Without a long introduction, Kenny suggested starting with a stand-up check-in. Who are you? What is your favorite thing to do? Is there a reason why you couldn’t participate fully today? Everyone shared their answers and gets more comfortable.
We moved on to agreements: “This is how we’ll work together in the coming 2 days.” By making things explicit, and creating this list together, we set a pretty good standard. The last part of the introduction was impromptu networking. In duo’s, we shared what we already knew, expected, and concerned us, while the other actively listens.
After that, we shared what we heard. It’s about listening. “I’m not a technical” person was a concern that was more frequently raised, whereas I thought I would be the only one. That was my biggest insecurity. It proved why this exercise was such a great idea. I’m not alone! Yay!
What does Domain-Driven Design do?
After a short break, we got into the essence of Domain-Driven Design, often referred to as DDD, with a few slides. “I’m not going to quote the entire book, but I’ll share some quotes and references,” Kenny told us. It quickly became clear to me that this would not be a ‘sit-back-and-relax’ kind of training. We would mainly be on our feet.
A couple of pointers stuck:
- The main problem that DDD solves is: ‘How can I make smaller models?’
- There will always be a design, so you better address it.
- We build software together – which is why we need a shared state of mind. That’s what DDD is all about: consistent language, shared understanding, social beings.
The social scientist in me was glad that this got confirmed. Like I said, I believe Domain-Driven Design is a way of dealing with complexity, creating abstraction and specific models for specific solutions. When discussing models, our internal team discussion about ‘friet or patat’ popped up. The challenge with language is, of course, that it’s not consistent and not the same for everyone. With Domain-Driven Design, we try to create small models with consistent language: multiple bounded languages, instead of one canonical language.
EventStorming for a fake domain
In this training, we used a fake domain on which we were all domain experts: a domain for going to the theater. This is what we would be modeling. Kenny first explained Model Exploration Whirlpool, starting with scenarios. We had to tell a story and be concrete. This is exactly where cognitive bias usually comes in.
Without too much theory, we dove into it. With a brown paper representing time, we all had orange stickies and a sharpie. My group split up into 2 groups of 4 people, each with their own brown paper.
Step 1 – Experiencing chaotic exploration
And oh boy, it is chaotic. Individually, we wrote domain events on the orange stickies – that were business-relevant (not databases and techy stuff!) and in the past tense – and we added them to the brown paper. It was an eye-opening and highly interesting moment how everyone came up with different events. We all made our mental models explicit, and that was a great starting point!
Step 2 – Enforcing the timeline
This is when we started discussing the topics. EventStorming is about collaboratively developing a shared language between different stakeholders, to create a common understanding of processes and the underlying software. It was up to us, as a group, to create a timeline with the events that we all agreed on. This meant we had to discuss and ask on many occasions “What do you mean with this sticky?” Stickies were removed, new ones were added, and we were continuously talking about what was on the board. This approach prevented us from getting into personal discussions about non-explicit issues. It seemed too simple…
Kenny let us do our thing. He didn’t interfere or steered us, but he was actively listening. Every now and then, Kenny introduced another colored sticky, which only helped us deal with the problems we were encountering. For example, pink stickies to identify hotspots: stuff we didn’t have a definite answer to right away, so we could mark it for looking into at a later moment. A legend of colors was built like that.
Step 3 – Finishing the storyline
At some point, we were happy with our timeline. Time to step back and reflect. Kenny then asked us what differences we saw when comparing the two brown papers. Very interesting to see how 2 groups can structure a timeline in completely different ways. That’s exactly the point: “There is no absolute truth. It’s about you as a group agreeing on something and sticking to it.” One person told the story based on the enforced timeline, which helped us to understand the process better.
Step 4 – Playing by the rules
By this time, Kenny showed us a process drawing with even more different colored stickies after which we started with ‘Process Modeling EventStorming’. Actions, systems, policies, information, actors… It was all in there and we started to shape the process using these new insights. It was truly amazing to see how much you can get done in such a short amount of time!
From process modeling to software modeling
After a well-deserved lunch, we start with an energizer. A fun game in which 2 groups competed with each other. We had to keep a conversation going around certain topics, but we could only ask questions. If you took too long, the next person in line would be up to the task. This was just what we needed to conquer our after-lunch dip – and it was great fun!
There was even an educational hook. Questioning is crucial for DDD. You can’t assume things, you should always ask questions. Kenny introduced us to Socratic questioning and explained how we can use that during EventStorming, for example.
Even though EventStroming is a really useful and great tool, it’s still a tool. It has blind spots. One of the events we put on the board included ‘best seats’, for example. What does ‘best’ mean? Combining visual collaboration tools can be a good way of conquering blind spots and cognitive bias.
“Combining visual collaboration tools can be a good way of conquering blind spots and cognitive bias.”
So, we started experimenting with Example Mapping. This tool is about challenging meaning, rules, and concrete examples. A great tool for user stories! We started working out our rules and examples and we visualized our examples, which really made things more concrete.
The end of Day 1 was near and our cognitive load was hitting its limit. In the final part of the day, we had to create an actual model. Part 2 of the Model Exploration Whirlpool: Model.
Domain-Driven Design is usually object-oriented, so that’s what we chose. Our challenge was to model one particular system that was part of the process we defined during the EventStorm. All we needed was a whiteboard, markers, and our visualized process. We drew, we discussed, we refined. Once both groups were happy with their model, we talked each other through the models. Again, no absolute truth, all models were wrong. All that mattered was to create the least wrong model that we all agreed upon.
And that was it for Day 1. We concluded with a check-out and writing down on stickies (what else…) what ‘wowed’ us that first day and ‘how about…’ items. This would be our starting point for the second day. But first: a good night’s rest!
Day 2 – Diving deeper into Domain-Driven Design
Our second day started with some coffee and looking back on the first day. The energy was up again, the group was excited and was looking forward to the second day. In the training room, we started with a ‘formal’ check-in, while reflecting on what’s on the ‘Wow’ board and the ‘How about’ board.
After that, Kenny told a bit more about himself, sharing some personal stories. For example, about how he ended up in the ‘IT world’ and how it’s related to what we’re doing here. His story about spaghetti structures leading to a big ball of mud resonated and confirmed why you should always improve the system as a whole if you want to be successful. Flying blind on Agile, Scrum, DevOps, Microservices…
“You can copy a model, but you cannot paste a model.”
If you want to remember anything from this post, let it be this quote. Put it on a tile and hang it in a prominent place. There are universal principles that you can definitely use, but you need to be mindful of how they will affect your own culture. And that’s where things go down the drain fairly often as people think: “It works for Google/Spotify, so it will work for us!” Rethink that.
Big Picture EventStorming
Loosely coupled architectures, that’s what we all want. Cross-functional product teams, organized around capabilities so that we have the least coupling in our domains. Sounds great. But how do we get there? This is the strategic part of DDD, and it’s about getting and shaping context.
The best way to start here is, again, EventStorming. However, this time on a higher level: Big Picture EventStorming. For this exercise, we all got roles assigned that we needed to play in the EventStorm. I picked ‘Content’ since that was a tiny piece of comfort in the non-comfort zone I still was in.
After we all got a description of our role, we started writing down domain events that were relevant to us and placed them, again, on the brown paper. Well, that led to chaos all over. However, Kenny’s facilitating skills were brilliant, which is why he introduced new tools just when we figured out ourselves that we needed something to lead us out of the chaos. Pivotal events, such as system boundaries, temporal milestones, emerging context, and swim lanes, help us visualize this process. I can definitely see how these workshops and visualizations can help in making strategic decisions in ‘the real world’.
Pretty soon, it became clear to us that it was kind of hard to stick to your role and its perspectives. You’re tempted to give input from your ‘real’ role and the knowledge you have. At the same time, being forced into a different role helps you overcome cognitive bias. The obvious advantage of this Big Picture EventStorming was that we were – again – creating a shared sense of reality.
Start by mapping the process. Due to all the different roles, you gain more insight and dependencies become clearer. Once you’ve mapped that out, you can start mapping systems and opportunities on the process we agreed on. It’s also a great way to identify hotspots.
On to the next strategic decision tool that could help us create context based on what we found in the Big Picture EventStorm: Context Mapping. Armed with markers and a whiteboard, we started drawing circles and defining their relationships. We used the processes identified on the brown paper as our circles: marketing, budgeting, accounting, etc. And we started drawing their relations. Unfortunately, we got a bit frustrated as we noticed that pretty much everything was related.
That’s where Kenny jumped in to introduce our next step: distilling the core. We identified our core domain, supportive domain, and generic domains. What was our moneymaker? How should we organize teams? Where were we focusing our energy? It all seems pretty trivial, but by visualizing this – literally having something to point at while discussing – it became easier for us to make decisions.
We go a little bit into the Cynefin framework, which made perfect sense at this point in the training. Dealing with complexity and decision-making by knowing the domain you’re in. We related this to Domain-Driven Design – how you should probably not use tactical patterns in an obvious domain, how DDD shines into complex domains, and that EventStorming mainly works in complicated and complex domains. A great way of putting theory into practice!
Context Mapping – Strategic Patterns
Kenny then explained the possible relations between contexts. It was a bit abstract and confusing as there are quite a few. We tried to identify strategic patterns on the context map we just created, and we got a bit frustrated (again). Kenny reassured us that this was normal and it just takes a lot of practice. It also gets easier once you start practicing with your ‘real life’ domains and contexts. The essence was that we understand that solutions depend on these strategic patterns. If you know what your domains look like (also in terms of communication), you can select your solutions better.
After lunch, it was time for an energizer again – ‘The Happy Salmon game’ this time. Luckily no one took pictures here…
Bounded Contexts and Aggregates
We then dove into a bit of theory about emergent bounded contexts. How we could identify them by looking at our brown papers, swim lanes, people on the brown paper, people in the room, body language. These are all different ways to recognize bounded contexts. After talking about it, we moved on to the Bounded Context Canvas, which we could use to decouple software correctly.
The Bounded Context Canvas seemed pretty simple, but it’s actually quite difficult to do – which seemed to be a returning theme in this training. Although you’d like to keep it simple, you’re still tempted to include a lot in that canvas. Our 2 groups came up with completely different ‘models’. In our group, we spent about 15 minutes defining ‘reservation’, ‘seat’, and ‘ticket’ – I’m not kidding you. Again, it sounds trivial, yet it was actually really hard and important to hash out before moving to the next step.
After completing the canvas, we started modeling. We all felt pretty confident and convinced that this would be easier than the first day. Boy, were we wrong… We got stuck in the model from the day before and found ourselves in the same discussions about entities and value objects. Maybe it’s because we had gained more knowledge. After all, ignorance is bliss, right?
Enter Aggregates! Implicitly, we already discussed aggregates. We just didn’t know it was called aggregates. Only after we experienced that we needed something extra to make sure the business rules were adhered to, Kenny introduced aggregates. He discussed a few theoretical aspects, shared his model and there we went again, trying to create different models with different aggregates. Bottom line is that we had to design small and accept that all models were wrong. We just had to find the least wrong model. That’s how we got to loosely coupled architectures.