Let's play a little game
Start by whispering something to your teammate, she will whisper what she heard to another colleague, and this colleague will do the same to another one and so on.
When we compare what was originally said and what the last person in the chain heard, we realize the meaning has been completely distorted. Now imagine you order a custom cake, you call the bakery to give them instructions. A friend of yours has graduated recently and you want a cake with a graduate cap, some flowers, and especially, you want sprinkles, lots of them. When you get the box and open the lid, this is what you find:
Have you seen these situations frequently during your career? I've heard things like:
I once worked with a team to analyse their historical bugs and we found 50% were related to misunderstanding of requirements.
I would honestly say [the project] was like 90% of the work we were doing was fixing ‘bugs’ that were misunderstandings.
Misunderstanding the requirements is just one thing that could happen. The code will reflect these misunderstandings, the gaps in our business knowledge, and more importantly, our organization's communication structures Conway's Law. The final state of our dysfunctional system could be summarised like this: we sure love our spaghetti code and our big ball of mud 🍝😍. Solving problems and delivering value through a business flow spans different areas, expertise, and knowledge, and optimising for local solutions won't make the complexity of the system more explicit, manageable, or the business processes clearer, because we only see a part of the whole system.
Enter Domain-Driven Design (DDD)
Domain-Driven Design is an approach that focuses on creating software in complex business domains that reflects the mental model of the people that intimately know the business. Instead of handing off requirements all the way down to the developers, passing from stakeholders, experts, and business analysts... we all create a single language and a shared model, which is used by everyone in the project and is reflected in the code.
Domain-Driven Design is all about dedicating time to discover and model our domain, using a shared language and being ready to embark on a journey of continuous collaboration and learning.
Domain-Driven Design is not meant to be a static, once-only process. It is meant to be a continuous collaboration between developers, domain experts, and other stakeholders. So if the requirements change, we must always start by reevaluating the domain model first, rather than just patching the implementation - Domain Modeling Made Functional, Scott Wlaschin
The domain and a model
This is a picture of London:
I'm rushing to finish this article because I have an important meeting in The Shard, how can I get to the meeting from Whitechapel? I don't know about you, but this picture doesn't help me much, there's no way to identify Whitechapel, The Shard, or any streets or landmarks to guide me. Somebody shares with me a different picture:
I can see Whitechapel and The Shard, I can even recognize some landmarks! I know where to go, this should be easy. This last picture is not reality, it's a simplified representation of London: a model. It allows me to ask specific questions and get answers. I can only ask specific questions since it's not all-inclusive, it omits information, it uses a single language and simplifies reality in such a way that it's useful for our particular purposes. If my fingers are tired from writing this article and I don't want to walk to The Shard, what tube station should I use? Our previous model doesn't help us, we need to use a different one:
The person I was going to meet has changed the meeting location, I have to meet him in Tate Modern. Our little map of London doesn't include Tate Modern, but if we adapt it to include more areas of the city, it becomes useful. If we extrapolate this to a business with complex rules and procedures, the domain would be what the company does and how it does it to achieve its goals, the domain is our picture of London. In order to work with this complex domain in such a way that we can clearly see the business rules, easily adapt and expand them while being able to use the same shared language, we need to model it.## Sounds good, how can I start modeling?
Software development is a learning process, working code is a side effect – Alberto Brandolini
The DDD community offers us several guidelines to model our domain:- Focus on business events and workflows.
- Partition your domain into smaller subdomains.
- Model each subdomain.
- Listen to the experts' language to guide you and use it with everyone and everywhere (code included)
Business events and workflows
When our domain is complex to the point that the whole is more complex than its individual parts complex adaptative systems, knowing to perfection our specific functional area won't really help us deliver a full system. In a world where we reign supreme over our silo, when it's time to create something that involves an entire business flow (which touches multiple areas) we don't have enough knowledge, we engage in constant hand-offs, sporadic meetings with different teams to gather more information and, in summary, lots of waste in the process. In the extreme case, we might think we don't need other people, that we can do it alone, we're the best.
The path towards reducing silos and optimizing for global problems is to start focusing on optimizing for flow, global understanding, and collaboration. Collaboration not only involves developers but also requires all involved areas of expertise to work closely. Breaking up silos and organizing teams for fast flow is not the topic of this article, for more information I highly recommend Team Topologies. Through collaboration with the business and technical teams involved in our domain, we can start getting a better view of it, foster global knowledge sharing, and go in a direction of creating our models and boundaries and interactions between them. Since we want to model a complex business domain, we'll focus on the behaviours of the business and its operations, one of the best ways to do that is to focus on business events and workflows.
A business doesn't just have data, it transforms it somehow. The value of the business is created in this process of transformation, so it's critically important to understand how these transformations work and how they relate to each other – Domain Modeling Made Functional, Scott Wlaschin
Event Storming is a highly collaborative workshop that brings together anyone who has questions and anyone who has answers: experts, developers, managers... The goal is for everyone (technical and non-technical) to engage in insightful conversations and discover our processes and understand and model the domain, which is achieved by creating a visual narrative of the business. Nothing beats a good story. We create a cohesive story of the business by focusing on the business events, the things that happened that the business cares about, e.g. Account Deleted, Payment Confirmation Email Sent, Booking confirmed. By creating a narrative together, we face our misunderstandings, resolve conflicts and discrepancies, discover the unknowns... Most importantly, we reach a single story of the business, instead of disjointed versions, we create a shared understanding. This rather simple concept, shared understanding, is the real outcome, not the wall of post its or documents after the workshop. While it's not the one and only tool to model the domain, Event Storming is one of the best ways to do it, since it involves everyone in the business flow or company, and it hopefully helps chip away at the silos and starts sharing knowledge and working on the global problems.
Every event is normally caused by doing work to satisfy an action, a command. When we get the Account Deleted event, that means there probably was a Delete Account command. For Payment Confirmation Email Sent, the command could've been Make a Subscription Payment, which caused the payment to be made, sent a confirmation email to the user, and turned on autorenewal. The command doesn't do the work, it only gives an order. The actual work is done by the workflow, which takes a command, actions it, and returns events. These events might trigger commands in other areas, with their corresponding workflows.
In this first part, we've seen that:
- A domain is what the company does and how it does it. The business and its operations.
- A model is a simplified version of reality that solves a specific challenge of the domain.
- Domain-Driven Design is an approach to software that focuses on modeling the mental models of the experts in complex business domains and shared understanding.
- Silos are optimal for local problems, but when working on business flows and complex problems, they hinder our ability to deliver and see the big picture.
- Event Storming is a great tool for shared understanding and modeling the domain. We see the business, in the most basic form, as a narrative composed of events.
- Command -> Workflow -> Events
In the next post, we'll talk a bit about partitioning the domain into smaller subdomains and model each subdomain. As well as how Event Storming can still help us in partitioning and discovering our contexts.
- Implementing Domain-Driven Design. Vaughn Vernon
- Domain Modeling Made Functional. Scott Wlaschin.
- Event Storming. Alberto Brandolini.
- User Story Mapping: Discover the Whole Story, Build the Right Product. Jeff Patton.