“Once we start judging, we stop learning.” 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 judgements.
That is why I decided to join the DDD Foundations training at Xebia.
For me, DDD is all about a way (or method, technique, approach, whatsoever) to create a shared sense of reality and dealing 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. Getting somewhere together; collaborative modelling together with business experts, stakeholders, UX, testers, and developers. Breaking the silos!
So, I was quite excited to join this 2-Day training from Kenny Baas-Schwegler. My personal goals were 1) to gain more and new knowledge on DDD in general, and specifically on tactical patterns, and 2) to challenge my current knowledge, biases and thinking patterns that I might be stuck in.
Day 1
Introduction
On a very early Wednesday morning, I’m heading to Xebia HQ in Hilversum, where the training course will take place. Starting with some coffee, chit chat and a little bit of waking up. We’re with 8 people. Pretty soon, it gets clear that this is a diverse group of people. Different backgrounds, interests and nationalities. ‘This will be fun!’, is my first thought.
The training room doesn’t look like your typical classroom – there are some papers with drawings on the wall, and there’s 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 suggest to start with a stand-up check-in; Who are you, what is your favourite thing to do and is there a reason why you couldn’t participate fully today? Everyone shares their answers and gets more comfortable. We move on to agreements – ‘This is how we will work together the coming 2 days’. By making things explicit, and creating this list together, we’re setting a pretty good standard here. The last part of ‘the introduction’ is impromptu networking. In duo’s we share what we know, expect and concerns us, while the other actively listens. After that, we give back what we heard. It’s about listening. “I’m not a technical” person was a concern that was more frequently raised. Where I thought I would be the only one, that is was my insecurity. That is why this exercise is a great idea! I’m not alone! Yay!
The Essence of DDD
After a short break, we go into the essence of DDD with a few slides. “I’m not going to quote the entire book, but I’ll will do some quotes and references.” It quickly becomes clear that this won’t be a ‘sit back and relax’ kind of training. We will be on our feet mainly. Few pointers that sticked:
- 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 DDD 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’ pops up. Because the problem with language is that it’s not consistent. With DDD, we try to create small models with consistent language; multiple bounded languages, instead of one canonical language.
Domains, Domains, Domains
In this training, we’ll use a fake domain on which we’re all domain experts: going to the theater. This is what we’ll be modelling. Kenny explains the Model Exploration Whirlpool first, starting with scenarios. We need to tell a story and be concrete. This is exactly where cognitive bias comes in.
EventStorming
Without too much theory, we dive into it. There’s a brown paper representing time, we all have orange stickies and a sharpie. The group is split in 2 groups of 4 people, each with their own brown paper.
Step 1 – Chaotic Exploration
And oh boy, it is chaotic. Individually, we write down domain events on the orange stickies – that are business relevant (not databases and techy stuff!) and in past tense – and we put them on the brown paper. It’s eye-opening and really interesting how everyone comes up with different events. We’re all making our mental models explicit, and that is a great starting point!
Step 2 – Enforcing the timeline
This is where we can start discussing. It’s up to us as a group to create a timeline with the events that we all agree on. This means we’ll have to discuss and ask ‘what do you mean with this sticky’ a lot. Stickies are removed, new ones are added, and we are always talking about what’s on the board. Which prevents us from getting in personal discussions about non-explicit issues. It seems so simple… Kenny let’s us do our thing; he’s not interfering or steering us, but he is actively listening. Every now and then, he introduces another coloured sticky, which only helps us dealing with the problems we were encountering. Pink stickies to identify hotspots for example: stuff we don’t have a definite answer to right now, so we mark it as something we’ll need to take a look at later. A legend of colours is being built.
Step 3 – Finish the storyline
We’re happy with our timeline. Time to step back and reflect. Kenny asks us what differences we see in 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 stick with it.”. One person tells the story based on the enforced timeline, which really helps us understand the process better.
Step 4 – Play by the rules
This is where Kenny shows us a process drawing with even more different coloured stickies, and we start with ‘Process EventStorming’. Actions, systems, policies, information, actors… It’s all in there and we start to shape the process using these new insights. It’s amazing how much you can get done in such a short amount of time!
From process modelling to software modelling
After a well-deserved lunch, we start with an energiser. A fun game where 2 groups compete with each other. We have to keep a conversation going around a certain topics, but we can only ask questions. If you take too long, it’s up to next person in line. This is just what we needed to conquer our after-lunch dip, and it’s great fun!
And there’s even an educational hook! Questioning is crucial for DDD. You cannot assume things, you should ask questions. Kenny introduces us to Socratic questioning, and explains 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.
Example Mapping
So we started experimenting with Example Mapping. This tool is all about challenging meaning, rules and concrete examples. Great tool for user stories! We started working out our rules and examples, and we visualised our examples – which was really making things more concrete.
The end of Day 1 is near, and our cognitive load is hitting its limit. The last part of today is about creating an actual model. Part 2 of the Model Exploration Whirlpool: Model. DDD is usually object oriented, so that’s what we’re going with. Our challenge is to model one particular system that is part of the process we defined during the EventStorm. We have a whiteboard, markers and our visualised process. We draw, we discuss, we refine. Once both groups are happy with their model, we talk each other through it. Again, no absolute truth, all models are wrong, it’s about creating the least wrong model that we all agree on.
And that’s it for Day 1. We conclude with a check-out and writing down on stickies (what else…) what ‘wowed’ us today, and ‘how about…’ items. This will be our starting point for the second day. But first: a good night rest!
Day 2
Starting our second day with some coffee and looking back on the first day. Energy is up, the group is excited and looking forward to the second day. In the training room, we start with a ‘formal’ check-in and reflecting on what’s on the ‘Wow’ board and the ‘How about’ board.
After that, Kenny starts to tell a bit more about himself. Sharing some personal stories about how he ended up in this ‘IT world’ and how it’s related to what we’re doing here. The story about spaghetti structures leading to a big ball of mud resonates and confirms 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 useful principles that you can definitely use, but you need to be mindful of how it will affect your culture. And that’s where things go down the drain fairly often: “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, organised around capabilities so that we the least coupling in our domains. Sounds great. 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, it will be on a higher level – Big Picture EventStorming. For this exercise, we’re all getting roles assigned that we need to play in the EventStorm. I pick ‘Content’, since it’s a tiny piece of comfort in this non-comfort zone.
We all get a description of our role and we start writing down domain events that are relevant for us and place them on the brown paper. Well, that leads to chaos. Kenny’s facilitating skills are brilliant, and he introduces new tools just when we figured out ourselves that we need something. Pivotal events as system boundaries, temporal milestones, emerging context and swim lanes help us visualise this process. I can definitely see how these workshops and visualisations can help in making strategic decisions in ‘the real world’.
Pretty soon it becomes clear that it’s 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 is that we are, again, creating a shared sense of reality. Starting with mapping the process. Because of all the different roles, you gain insight and dependencies become clear. Once you have that mapped out, you can start mapping systems and opportunities on the process we agreed on. It’s also a great way to identify hotspots.
Context Mapping
On to the next strategic decision tool that will help us create context based on what we found in the Big Picture EventStorm. Armed with markers and a whiteboard, we start drawing circles and define their relationships. We use the processes identified on the brown paper as our circles; marketing, budgeting, accounting, etc., and we start drawing relations. We get a bit frustrated as soon as we notice that pretty much everything is related.. That’s where Kenny jumps in to introduce our next step: distilling the core. We identify our core domain, supportive and generic domains. “What’s our moneymaker? how should we organize teams? Where are we focusing our energy?” It all seems pretty trivial, but by visualizing it, having something to point at while discussing, it becomes easier to make decisions.
We go a little bit into the Cynefin framework, which makes perfect sense at this point in the training. Dealing with complexity and decision making by knowing the domain you’re in. We relate this to DDD – how you should probably not use tactical patterns in an obvious domain, how DDD shines in complex domains and that EventStorming mainly works in complicated and complex domains. Great way of putting theory into practice!
Context Mapping – Strategic Patterns
Kenny introduces the possible relations between contexts. There are quite a few and this is where it gets a bit abstract and confusing. We try to identify strategic patterns on the context map we just created, and we get a bit frustrated. Kenny reassures us that this makes sense and it takes a lot of practice. It also gets easier once you start practicing with your ‘real life’ domains and contexts. The essence is 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’s time for an energiser again – ‘Happy salmon game’ this time. Luckily no one took pictures here…
Bounded Contexts & Aggregates
We then go in a bit of theory about emergent bounded contexts. How we can identify them by looking at our brown papers; swim lanes, people on the brown paper, people in the room, body language.. All ways to recognise them. After talking about it, we move on the Bounded Context Canvas, which we can use to decouple software correctly.
It seems pretty simple, but it’s actually quite difficult to do (which is a returning theme in this training…). You want to keep it simple, but you’re tempted to include a lot in that canvas. Our 2 groups come up with completely different ‘models’. In our group, we spent about 15 minutes on defining ‘reservation’, ‘seat’, and ‘ticket’ – I’m not kidding you. Again, sounds trivial, actually really hard and important to hash out before we start modelling.
After completing the canvas, we can start modelling. We all feel pretty confident and convinced that this will be easier than yesterday. Boy, were we wrong… We’re stuck in our model from yesterday and find ourselves in the same discussions about entities and value objects. Maybe it’s because we have more knowledge now.. 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 are 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 need to design small and that all models are wrong. We just have to find the least wrong model. That’s how we get to loosely coupled architectures.
Final thoughts
That’s it! Two intensive days, but somehow, everyone is still full of energy. All credits to our trainer, Kenny, here. In his way of training, he keeps everyone involved and manages to maintain a high level of energy.
Pro tip: If you don’t like standing up a lot, moving around and actively learn, this training might not be your cup of tea. But honestly, this is one of the best trainings I ever joined. Because of the active state that is required. Some trainings have obligatory interactive parts, but this a whole other ballgame. No classroom training with boring slides and a lot of theory, just getting your hands dirty and learn from your own failing – or struggling.. Which, I believe, is the best way of continuous learning!
Evelyn van Kelle 