I have been involved in several Agile transformations. Every company I’ve worked for asks the same questions: How do we divide the current software into teams, and how do we align these teams to our business goals? In this report, I’ll share my experience helping companies move toward Agile autonomous teams using a Domain-Driven Design approach.
1. INTRODUCTION
My name is Kenny Baas-Schwegler. I’m a strategic software delivery consultant for a Dutch consultancy firm called Xebia. I focus my work on software architecture and how we design teams and software together in a symmathesy called “socio-technical architecture” and highly align these to business goals. I do this by facilitating visual meetings. I thrive on chaos, but I focus on developing structured software.
I’ve been involved in several transformations over the years, from DevOps to Digital to Agile. These transformations typically focus on transitioning people into near-autonomous teams of no more than eight people who will work in an agile manner. Every company I’ve worked for asks the same questions at these transformations: How do we divide the current software between the teams, and how do we align these teams to our business architecture?
To address these questions, companies request my help to design microservices using a Domain-Driven Design (DDD) approach. This approach makes it easier to distribute the software between teams based on identified boundaries, called “bounded contexts.” While I believe enterprises involved in an Agile transformation need at least a Domain-Driven Design approach to create autonomous aligned teams with a loosely-coupled architecture, this process presents unique challenges. In this experience report, I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams. I’ll call the company Lowlanders. I also discuss more generally the DDD practices that I find most effective.
2. BACKGROUND
My focus on structured software and architecture probably stems from my background in embedded electronics engineering, where having a well-designed printed circuit board was vital. With my naive student mind, I succeeded as a software engineer in large financial corporations and was astounded at how overly complicated the software design process was!
Observing this mess, I started looking for answers to why this was the case and found a big blue book written by Eric Evans called Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). I found this book challenging, as it’s not something you’d read cover-to-cover in a week.
I was struggling even more at work, because the company I worked for had also made an Agile transition which required doing twice the work in half the time. The team was struggling with how to divide itself into Agile teams. Despite a good deal of knowledge sharing, the monolithic software application was hard to split up. We started with 14 people on one team. While Scrum, the Agile framework we began with, already helped us manage our work, we certainly did not do twice the work in half the time. My gut feeling told me that DDD would help us split into more autonomous teams. But since DDD was so new to me, I wasn’t able to sell this idea to management.
Luckily for me, an application redesign made it into our backlog, and this was the perfect moment to try DDD. We were able to divide that application and lower the coupling with the existing landscape. We started with two developers and a product owner. Within a few sprints, we were able to go safely to production without hurting the current applications. This was a great success for the team, as we could now apply a DDD workshop in-house. We also knew we’d now be able to approach software architecture with DDD.
After five years, I figured out that I get joy not from using new technology but from solving complex domains. I therefore left my first company and became a consultant to further hone my skills in software architecture for complex domains. This report will describe several patterns I witnessed at the companies I consulted with, focusing on my experience at Lowlanders.
3. MY STORY
Lowlanders is part of a more significant financial corporation that sells flexible mortgages. Business and IT are separate departments on the organizational chart. Before I joined, they had a legacy monolithic “big ball of mud” application landscape, which is common in large financial corporations. They had already started an Agile transformation, and the IT department was completely overhauling their IT landscape, targeting microservices as a solution to disentangle their “enterprise spaghetti.”
The IT department manager hired me to consult on DDD. I needed to help disentangle their system landscape and transform it into autonomous teams who would build microservices on the new technology stack.
3.1 What is Domain-Driven Design?
Domain-Driven Design is a holistic approach to software development. Eric Evans coined DDD in his 2003 book, addressing the difficulties software teams have in building software autonomously. Multiple teams design and build complex solutions as monolithic software that usually employs only one model to solve many different problems. He also discussed the ambiguity between the language the business speaks and the language within the model, causing confusion and entanglement within and between teams.
A great example of such ambiguity is a company’s perception of the customer. Companies usually think of customers from only one angle, but there are actually multiple different contexts for customers. For example, in the Netherlands a customer can generally sign up for new health insurance once a year. To do this, the customer must cancel their old insurance before the new year begins and purchase new insurance within the first two months of the year. Most Dutch people switch insurance companies one to two months before the new year to play it safe. During these last two months of the year, health insurance companies are limited if they only perceive customers as they do at other times of the year. While a customer who has switched to a company’s policy is not yet an insured customer, they may have questions or problems that need to be addressed. In that case, the company needs to view them as a customer eligible for customer support. In this example, we see much ambiguity and many exceptions.
To solve this problem, Eric created the concept of a bounded context, a pattern to divide software based on a model of consistent language. Within the bounded context, we create a shared language through conversations between business specialists and software people. This becomes the ubiquitous language. We focus on a language that concisely describes the situation within the domain. Instead of one canonical language for the entire business, we create several bounded contexts, each with their specific language and model.
Within a bounded context, one team can take ownership of its model and increase its autonomy as team members develop software. They can test in isolation, since teams have a clear vision of who their customers are and can receive their own feedback metrics. Studies by Nicole Forsgren Ph.D., Jez Humble, and Gene Kim (2018) have shown that the strongest predictors of continuous delivery performance and successful organizational scaling are loosely coupled teams enabled by loosely coupled software architecture. This makes the bounded context a very important pattern if you want to accelerate!
3.2 Domain knowledge – the problem space
While using bounded contexts to divide models within DDD offers increased autonomy, I do not believe in total autonomy for teams. There will always be coupling between systems and teams. Only by designing clear boundaries, and by deciding what goes where and how things move between boundaries, can we create autonomy. Using the bounded context pattern, we can lower the coupling between teams and give each team a unique purpose.
The first step in defining clear boundaries is to gain knowledge of the domain. I discovered this early in my work with Lowlanders. My first session involved a couple of business stakeholders, a product owner, and many developers. The product owner and business stakeholders all had a good deal of domain knowledge, which felt great because I knew we at least had the right people in the room. After the two-hour session, all the developers were thrilled with the results, saying, “We finally have more insight into the software we need to build.” However, the stakeholders and product owner were less happy. In a private conversation, they told me, “We already knew everything that was discussed.” While talking more with the developers, I also learned that they each used different descriptions of the business and had differing perceptions of the business domain. This example shows that designing bounded contexts for a business is hard if teams lack knowledge of the domain or have different understandings of it. If this lack of knowledge continues, IT teams won’t build the right software, and the business, and eventually the customer, will never get what they truly need.
So to get a shared understanding of our domain, we must first dive into what we call in DDD the “problem space.” Mathias Verraes explains the problem space as “our world as we perceive it.” It is the problems, models, and architecture of the business. As software engineers, we must understand just enough about the problem space to build the right solution. As software engineers developing solutions for these problems, we must understand the knowledge of the problem first-hand. More importantly, we must continue to gain an understanding of the problem space as we go on. Although the problem space is usually stable, it can change when we gain new insights.
These insights can come from the business side or from software engineers. It’s a collective effort, and this fact poses the biggest problem in doing Domain-Driven Design. In most enterprises, software teams are treated as factories. You give the teams a functional design, and they’ll deliver software. That is not the case with DDD, because as quoted by Alberto Brandolini: “It is not the domain experts knowledge that goes to production, it is the assumption of the developers.”
4. COLLECTIVE KNOWLEDGE BY COLLABORATIVE MODELING
Much domain knowledge can be grasped from the business architecture. In the past, I’ve found that even if a company has a business architecture, it’s usually outdated or is not aligned with the company’s collective perception. This is the overall problem with documentation. While documentation is still essential in knowledge acquisition, especially for historic knowledge about why decisions were made, it’s difficult to create documentation of the current architecture and keep it up-to-date. I believe that you do need documentation in the form of diagrams and visualizations, but these still require explanation from the person who creates them in order for others to gain insights.
Unfortunately, Lowlanders did not have a business architecture, so we needed to establish one. The best way to do this is to gather the collective knowledge within the company. The people hold that knowledge.
This process requires face-to-face collaborative modeling. To do collaborative modeling, we must invite the right people who collectively know the entire business line to a six- to eight-hour session. At the start of my assignment at Lowlanders it was hard to find a list of these people, and it was nearly impossible to find a four- to six-hour slot when they were all available. So I relied on the IT manager to tell me who the right people were and to find a “sweet spot” in which the greatest number of people with the most knowledge would be available.
Sending the invitations also posed a challenge. How were we going to sell such a workshop to these vital business stakeholders who already didn’t have much time? Here politics and good marketing came in handy. If I can figure out their pain and link it to the benefits of attending this workshop, they’ll be more willing to come. At Lowlanders, I reached out to the stakeholders and conducted open interviews to find the pain points that would sell the workshop to them.
When I had enough information, I determined the right time and invited everyone. I made sure the essential people with the most knowledge could come. I also wanted to keep the meetings open to all relevant people. I always want to include people, because the more insights they have, the better their business and software will be. However, I do need to manage the number of invites. I only had two colleagues to help with this workshop, and I can only personally facilitate up to 30 actively contributing people.
4.1 Visual Meetings with EventStorming
Once we get everyone with the right knowledge in the same room, we’re ready to do the collaborative modeling. To obtain the most domain knowledge from a collaborative modeling session, we need to conduct the meeting differently from the way we do traditional meetings. You’re probably very familiar with these traditional meetings, where we sit around a table discussing things.
Learning is complicated, and there is no one way to learn. However, brain science shows how we can be more effective at learning. I find especially useful the Six Trumps that Sharon Bowman discusses in her online article ““Six Trumps: The Brain Science That Makes Training Stick”:
- Movement trumps sitting.
- Talking trumps listening.
- Images trump words.
- Writing trumps reading.
- Shorter trumps longer.
- Different trumps same.
Companies underestimate the power of these trumps. In my experience, a big whiteboard, a large space to work with sticky notes, and asking people to share knowledge visually increases knowledge sharing greatly. But we can’t just throw stickies at a wall and expect it to work, and we can’t come in with a technique that requires a lot of time and certifications to learn. We want just enough structure to start sharing. One of my favorite tools is EventStorming, developed by Alberto Brandolini. I’ve been using EventStorming ever since Mathias Verraes showed it to me in his three-day DDD workshop five years ago. The power of this tool for exploring and learning complex domains amazed me. I’ve probably used it more than 200 times since then, for different types of workshops. I even used it as a tool to plan my recent wedding, with great success!
EventStorming is a flexible workshop format for collaborative exploration of complex business domains. You can jump right in and learn it quickly and easily. It comes in different formats, allowing you to share big picture vision and knowledge and also to understand a specific process and dive straight into the solution space. The setup is straightforward. It involves finding a wall big enough to hang paper on, inviting the right people (those with knowledge and those who implement that knowledge), and giving everyone the same specific color of sticky note (preferably orange) and a pen.
The workshop environment is very important, requiring enough wall space, fresh air, and snacks, such as chocolate. Nothing kills a 30-person workshop more than a lack of oxygen or sugar! You also want people to stay active, so too many chairs can be a problem. I usually include a few chairs so I can see when people are overwhelmed and need a break. As soon as people sit down, they probably need a rest and I try to confirm that with the group.
4.2 It’s not about IT
To get a shared understanding of the entire domain and start designing bounded contexts to move towards autonomous aligned teams, I use a specific EventStorming format called “Big Picture.” My first step in the Lowlanders Big Picture EventStorming session was to ask participants to start writing down domain events. A domain event is relatively simple to understand. It’s something that has happened or that can happen, something that’s important for the business to know. Examples for Lowlanders included:
- Mortgage request received
- Mortgage application passed
- Tender signed
- Declaration rejected
I told the participants that we don’t want to include any technical events — no databases connected, no application names, and certainly no Excel. We want to use only business-relevant language. I don’t enforce these rules at the start, however, because I’d rather have them get their first ideas down on paper. I ask them not to think too much about how they write things, just to write what comes to mind. It’s most important for everyone to share their perceptions, and something written on a sticky note can be much more easily refactored and rewritten than production code. I demonstrated this by crumbling a sticky and throw it on the ground in front of the brown paper and tell them “a good session would be to have lots of these stickies on the ground in the end.”
Participants wrote the domain events they’re familiar with on one sticky per domain event. I let them do this on their own so they can record their own perspectives. I can’t stress enough the importance of this process. We want people to put their perspectives into what I call the “shared pool of understanding” (e.g. the brown paper on the wall). These perspectives bring out language disagreements and misunderstandings, which we want to clearly see.
I tell people that there will be chaos but that we will eventually bring order to it. I get a lot of laughter when I tell them this, although some people became worried. I’ve found that many people can’t easily handle this unstructured agenda at the beginning, which is why it’s so important that I tell people everything will be fine.
At first, people have many questions about what to write down. For example, they asked if an event is in scope and want to know what they’re allowed to write. I don’t answer these questions, as my answers could bias their writing. I do notice, however, that some people won’t start writing at all because they seem lost. This is stressful for me as a facilitator. How can I unblock people who don’t write, without biasing them too much? I try to be as transparent as possible as to why I don’t want to answer their questions right away. I share examples from other domains and show them what a domain event is, but I don’t explicitly tell them what to write about. I’ve had some very awkward interactions with certain participants in which I could feel their anxiety and sense them slipping into a mental blockage. I’ve had to make myself endure these moments and remember that I can’t make everyone happy or convince everyone at the beginning.
As soon as everyone is busy writing their domain events and the room is quiet, I generally feel even more nervous. People are totally silent, and I’m in a state of uncertainty. This is normal, but it’s also uncomfortable for me. I now have time to think and to worry that the success of my assignment will be decided in the next 15-20 minutes.
I’m most concerned that people will hesitate to write down everything they know. It’s important in this process for people to be transparent about their knowledge. Unfortunately, that transparency is often discouraged in corporate culture, which is usually either pathologically power-oriented or bureaucratically rule-oriented. Successful knowledge sharing and domain discovery requires that people be allowed to be wrong. To foster this openness and vulnerability, I use two facilitators, an active one who steers the workshop and a passive one who observes. The observing facilitator can pick up a good deal of valuable information that the information sharing might miss. Considerable knowledge resides in the culture and in the way people interact with each other. These observations have a significant impact on the way the teams will strategically design their software later on.
As soon as people feel ready, they can start putting the stickies onto the paper on the wall. The paper represents a timeline from left to right. I ask them to put stickies on this timeline according to their perspective. This part requires facilitation, because we are entering that difficult zone of disorder and chaos. Expectation management is again critical. I want to let things happen spontaneously, but I also need to manage people who get bogged down by the chaos. One way I mitigate the chaos is to always have a flipchart where I write down a legend of the symbols, and an agenda if needed.
4.3 Enforce the timeline
Once everyone writes their domain events, it’s time to address the chaos. I ask participants to start with “enforcing the timeline.” This means to collaboratively structure and merge the timeline events in the way they think fits best. I ask them to place two stickies close to each other and decide which one comes first. At the Lowlanders workshop with 30 people, small groups formed around certain areas of the paper. Within these groups, it became clear who felt strongly about particular events. When this happens, these groups create natural knowledge boundaries and boundaries of different needs. These observations provide insights that help later in designing bounded contexts.
To further structure the EventStorm, I introduce the concept of pivotal events. Pivotal events are the specific events that are most important to the business. They are prerequisites for everything that comes after them. The people in the room collaboratively determine what a pivotal event is.
As soon as we select these pivotal events, we start to look for specific processes within them. Usually, swimlanes start to emerge that correspond to parts of the business flow owned by specific teams. We then start to argue about what comes between the pivotal events and these parts of the business flow.
We also identify and eliminate double events. If two events appear to be the same, I ask one of the writers to explain the event’s meaning. Since language can be ambiguous, one domain concept can use the same language as a totally different domain concept. For instance, Lowlanders use the word “pieces” in different ways. Their customers are required to deliver “pieces” to show proof of their salaries in their mortgage requests. In another context, the word “piece” describes all the components of a mortgage. Lowlanders also call the “pieces” in mortgage requests “burden of proof.” As you can imagine, this ambiguity causes a good deal of confusion, especially when we assume that one term refers to a certain concept when it’s actually something completely different.
You may therefore wonder whether we need a canonical data model after all. But it’s impossible to make a language consistent over an entire line of business. Any anthropologist will tell you that language is fluid and subject to people’s whims. Language evolves, as it should. Because language changes to accommodate new users, older users resist and complain. Instead of creating one big canonical language, it’s better to make smaller, more uniform bounded contexts with consistent language. Ambiguity is subtle, it’s everywhere, and Big Picture EventStorming reveals this ambiguity and lets us define the possible boundaries.
4.4 Focus on how events happen, and by whom
I follow the guiding heuristic that suggests we resist the temptation to figure out why events occur and instead focus on how they occur. This is most important in EventStorming’s earlier stages, before it’s more consistent and complete. When small groups form around particular events, I focus on how people talk, and I ask open questions. Many people start explaining exactly what they do and move away from the events on the paper. I then need to increase my facilitation skills to make the conversation concrete. I ask them to point to a specific event each time they explain how they do something. I also ask them to tell me who — what actor — is creating these events in the process. I use a small sticky here to add that actor to that part of the event.
A great way to know if the EventStorming is complete is when a structure is emerging on the paper that people feel happy about. At this point, I have them create a narrative of the whole EventStorm. I ask for a volunteer to walk everyone through the events process, step by step. At Lowlanders, a product owner volunteered to do this. If no one volunteers, I generally do it myself.
In the Lowlanders meeting, a vision of the company’s total business model had started to emerge. At this time, more discussions and disagreements started to happen. A powerful way to illustrate these disagreements is to place a bright red or pinkish sticky note in the locations on the paper corresponding to these arguments. If any other constraints on the business flow arise, we want to visualize these with such a sticky note as well. Examples of these constraints at Lowlanders included:
- People still needed to do manual audits, which take a lot of time.
- We already have the customer information, but we make them fill it in. This is not customer-friendly.
- We are ping-ponging tasks with another team.
Many interesting things happen when you begin the full narrative, and we need to pay close attention to the conversations that arise. At Lowlanders, the product owner started to discuss part of a swimlane, and another product owner began to disagree. They discussed it briefly, and the product owner then wanted to move on without changing anything or coming to an agreement. We observed this pattern often at Lowlanders, with participants trying to avoid conflict. But we can’t grow without conflict, as we all have different perceptions of the truth. In order to really find out what was happening, I intervened and asked if everyone could come to an agreement. We needed to decide whether the argument had been settled with some clarity or whether it should be tagged as a constraint. They agreed that they could not settle the disagreement at that time, and we placed it as a constraint on the board.
4.5 Mapping systems, constraints, and opportunities
Once we’ve captured the entire line of business in the EventStorm, we can start mapping the system onto it. Mapping systems provides a good overview of the current application landscape and how it matches the business. Before we finish the workshop, I let participants write down constraints I have not put up, and I also have them add opportunities. It’s important that people take the time to read these additions and that each person has an opportunity to talk about them for two minutes without others interjecting. This creates a shared understanding of each other’s challenges and concerns.
At the end of the day, we finish the workshop and ask everyone to vote for a constraint or opportunity they think will help the entire line of business the most. We give each person two arrows to place on the wall indicating their votes. The one that gets the most votes becomes the “theory of constraints,” the bottleneck that needs to be fixed.
The EventStorm leads to a shared understanding of the business, of where constraints occur in the business flow, and of emerging boundaries. It’s very helpful to leave the completed paper on the wall as a snapshot of the EventStorm. This allows participants to explain the results to others. We want to keep it as it is and not change anything after the workshop ends. While I find it most effective to leave it on the wall and have people who were there to explain it to people who weren’t there, we can also record a video of someone explaining the narrative. And, if needed, we can extract this knowledge to update our current documentation.
5. ARCHITECTURAL DESIGN AND DESIGNING BOUNDED CONTEXTS
“Architectural design is system design. System design is contextual design — it is inherently about boundaries (what’s in, and what’s out, what spans, what moves between), and about tradeoffs.” —Ruth Malan
A trained Domain-Driven Designer can start visualizing emergent bounded context in the big picture. We call these “emergent” because, from a big picture overview, we still don’t know enough to provide rigor to the bounded context. The problem at Lowlanders was that people were not trained to visualize emergent bounded contexts. They therefore needed some assistance with this visualization. Their domain experts also needed to share an official workshop outcome. I therefore started designing a context map with the emergent bounded contexts. To do this, we can use several heuristics:
- Pivotal events form hard boundaries and relationships.
- Swimlanes are potential bounded contexts.
- Different actors are potential boundaries.
- Domain experts’ areas of expertise are potential boundaries.
- Conflicting needs are potential boundaries.
- Behavior of language is different.
Based on these heuristics I began to draw a context map on my whiteboard book and eventually drew it on my tablet. In doing this with Lowlanders and others, I’ve noticed that this visualization, although a snapshot, is a collective perception of the people in the room and provides an excellent basis for conversation. This conversation can lead to decisions to move forward with the design of bounded contexts and into the solution space.
5.1 Solution space
Mathias Verraes describes the solution space as “our solution as we design it (and constrained by the forces you mention).” It’s the space in which we do software architecture to manage complexity and where we deliberately design a ubiquitous language that’s unambiguous, agreed upon, and rigorous. The bounded context design is linked to the business and has a strategic domain model. Rebecca Wirfs-Brock provides a good explanation of a model: “A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind. There is no wrong unless you intentionally leave out or overemphasize on purpose to mislead.”
5.2 Designing software teams and aligning to business — socio-technical architecture
At Lowlanders we now took an emergent bounded context, invite the teams who will potentially implement software in that domain (and other relevant people), and start yet another collaborative modeling session. This time, we use Process and Software EventStorming to clearly define our bounded context and design a potential model to solve the problem. We might use other techniques like Example Mapping, Impact Mapping, or User Story mapping to start visualizing more. The group that is present can decide which team will start working on which bounded context, how they’ll stay aligned with the business, and which strategic patterns they’ll use. Off course coached by an architect with the experience and knowledge to aid them, in this case me.
Designing software with all team members present creates a shared understanding and a shared ownership. We want to design teams and software who highly align to business value, which we call “socio-technical architecture,” to make sure we have the least amount of handovers from business idea to production, creating autonomous aligned teams.
6. CONCLUSION
Domain-Driven Design and Big Picture EventStorming are powerful tools for sharing knowledge and creating a shared vision of the entire business line. In this shared vision, we can also collectively determine the most significant constraints on our business strategy. Improving each part of the system in isolation will never yield the same results as looking at the system as a whole. We want to improve our efforts where it matters most, in the areas where they have the greatest impact on improving performance. A Big Picture EventStorming session is a perfect opportunity to visualize this change.
What I observed at Lowlanders is that IT teams couldn’t act and didn’t want to do anything if business didn’t allocate the time. For example, engineer teams didn’t always get time to learn the domain knowledge they needed to build the right things. The teams were happy doing EventStorming sessions to increase their domain knowledge, but the product owners complained, “I already know all of this, and it takes so much time.”
After talking more with the product owners, I could understand their perspective. They have the same situation with their management. They have targets to make, and they require certainty. So if we want to start creating better software, the alignment between business and IT is crucial.
To achieve alignment, we need to stop thinking in terms of business and IT and start acting as an integrated team. EventStorming helps us do this by breaking down the barriers between business and IT. It enables us to share knowledge about what we do, why we do it, and how we do it. By designing bounded contexts, we can ensure that a single team has the autonomy it needs to independently develop and release software aligned with business goals. It is not easy, but in my honest opinion, it’s the only way to build good software and swim with the faster fish!
7. ACKNOWLEDGEMENTS
I wish to publicly thank the teams I worked with for this project, but the company requested to remain anonymous.
My biggest thanks go to Rebecca Wirfs-Brock for giving me her time, feedback, and insights as I wrote this experience report. I want to thank her even more for being one of the most significant role models and inspirations in my career. Rebecca is kind-hearted, full of knowledge and wisdom, and an honest person. I loved working with you on this report.
I would also like to thank the entire Domain-Driven Design community, which has helped me to continuously improve. I want to name some specific people from the DDD community: Eric Evans, who started DDD; Mathias Verraes for starting my practical journey into DDD; Alberto Brandolini for all his insights but especially for creating EventStorming; Ruth Malan for all the insights she shares about software architecture; and Nick Tune for all his insights in Socio-technical architecture. I must also thank all my colleagues at Xebia who support me and give me constant insight.
I must end with thanking the most important person in my life, my beautiful wife, Vanessa Baas-Schwegler. Without her intelligence, feedback, kindness, and her being “almost” always right, I would never be the person I am today.
REFERENCES
Bowman, Sharon L. “Six Trumps: The Brain Science That Makes Training Stick” https://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf
Bowman, Sharon L. Using Brain Science to Make Training Stick. Bowperson Publishing and Training, Inc., 1st printing edition, November 29, 2010
Baas-Schwegler, Kenny. blog, “EventStorming the Perfect Wedding” https://baasie.com/2018/08/17/eventstorming-the-perfect-wedding
DDD Europe, “Domain-Driven Design: The First 15 Years” E-book published at https://leanpub.com/ddd_first_15_years (see “Discovering Bounded Contexts with EventStorming” by Alberto Brandolini)
Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley, 2003
EventStorming, website: https://eventstorming.com
Forsgren, Nicole, Ph.D., Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 1st edition, March 27, 2018
Nellen, Ted, CyberEnglish blog, http://tednellen.blogspot.com/2013/04/language-is-fluid.html
