EventStorming cheat sheet

EventStorming is the smartest approach to collaborate beyond silo boundaries. The power of EventStorming comes from a diverse multi-disciplined group of people who, together, have a lot of wisdom and knowledge. While it originally was invented for a workshop to model domain-driven design aggregates, it now has a broader spectrum. From gaining a big-picture problem space of the whole domain to gaining insight into the entire software delivery flow and creating a long term planning. Every one of these workshops has the same basic requirements and needs. In this EventStorming cheat sheet post, I will describe these basic requirements in a cheat sheet.

(more…)

Cultural needs designing bounded contexts

Without a doubt, the bounded context pattern from Eric Evans book domain-driven design is one of the more essential patterns for designing and building modern software. Especially in the land of microservices architectures, where setting proper bounded context which is highly linked with the business goals aka the domain is essential to not get into the distributed monolith anti-pattern. The bounded context is in its core a language boundary, a boundary where language can stay consistent and which is the boundary of the model designed for a purpose. Boundaries for people are crucial from a culture perspective. People cannot live without boundaries; it is a way in which we can define our self and separate us from the rest. To define our self creates an identity, a feeling of belonging which in time can create ownership. However, to be able to define our self, we must also define the others to keep our own identity. When we look at cultural anthropology, we traditionally did this on the border through get-togethers like marketplaces, where we exchange goods. Now if we want to keep the cultural benefits of the bounded context within our company, we must also take care of the cultural needs designing bounded contexts. In this post, I describe these culture needs when using the bounded context pattern.

(more…)

Towards Autonomous Aligned Teams with Domain-Driven Design

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.

For Agile Alliance I have created an experience report where I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams. You can find the report here:

A quest in finding the perfect EventStorming backpack

Over recent years, a tool called EventStorming became one of the go-to techniques for Domain-Driven Design consultants to collaboratively explore complex business domains at customers. Since consultants travel a lot from company to company helping with their questions about approaching software delivery this poses a small 1st world problem; How can we still comfortably travel while still carrying the required equipment to do an EventStorming at the customer (without breaking our back or needing a personal fitness coach). This was exactly the conversation we, Maxime Sanglan-Charlier and Kenny Baas-Schwegler, had during DDD Europe 2019. In this post, Maxime and Kenny will share their quest in finding the perfect EventStorming backpack.

(more…)

Visualise coupling between contexts in Big Picture EventStorming

A Big Picture EventStorming is a type of EventStorming where you get business and IT from an organisation into one room to explore the entire line of that business. This way we can find competing goals, ambiguity in the language, communication boundaries between contexts, and most important we share knowledge! We end up with a visual overview of our business architecture and can map our IT systems on or do for instance a value stream mapping. But we can also map and visualise coupling between contexts in Big Picture EventStorming. In this blog post, I will share my insights on how I visualise contexts boundaries in a Big Picture EventStorming.

(more…)

Heuristics on approaching Example Mapping

While Bruno Boucard, Thomas Pierrain, and I were preparing our DDDEurope 2019 workshop, we discussed how to approach Example Mapping. For the workshop, we were combining EventStorming and Example Mapping to go from problem space to solution space. The way I have been approaching Example Mapping was slightly different then Thomas and Bruno did. Mine followed up more on EventStorming, standing in front of a wall storming examples first with stickies. Bruno and Thomas do it the way that was described byMatt Wynne from cucumber, standing in a group around a table, starting with a user story and one rule written on index cards. So we began to discuss in short what these difference are, and what the trade-off was when we did these. In this post, I will explain the different heuristics on approaching Example Mapping in this post.

(more…)

Model Exploration Whirlpool – Domain-Driven Design: The First 15 Years

with EventStorming and Example Mapping

This article was published in the leanpub book: Domain-Driven Design: The First 15 Years

Introduction

People often ask for more concrete guidance on how to explore models, especially in an Agile or Lean setting. The model exploration whirlpool is Eric Evans attempt to capture such advice in writing. It is not a development process, but a process that fits in most development processes. The central theme revolving the process is to keep challenging the model. While the process itself for most is straightforward and easy to understand, there are not many concrete examples to find on how to do such a model exploration whirlpool. Most people when starting to use Domain-driven design (DDD) are looking for these practical examples. In this article, I will tell you my story of how I used the model exploration whirlpool by combining EventStorming, a technique that came from the DDD community, and Example Mapping, a technique from Behaviour Driven Development (BDD) community. 

(more…)

EventStorming; Continuous discovery beyond software modelling

Moving towards a microservices architecture

We see a lot of companies are moving towards a microservice architecture. The big pitfall of microservices architecture is to focus on the technology, how big the microservice needs to be, how many lines of codes, what entities do we put in a microservice, and using rest as the communication between them. But to succeed we need to focus on the problem space, by crunching domain knowledge and do domain modelling. EventStorming is a perfect fit for domain modelling, and almost all the microservices leaders seem to agree. Even ThoughtWorks finally put EventStorming on ‘adopt’ in their most recent rendition of their technology radar. But EventStorming has grown to be more than just a tool for domain modelling and to be successful and create autonomous teams you need to use EventStorming for more than only domain modelling.

(more…)

EventStorming and how to monitor Domain Events for product management

We design, model, and create software to solve a problem for our customer (this can also be a customer from within the same company). Only when we do so, we focus naturally on solving the happy path and want to deliver that value as soon as possible. The only problem here is that we will always come to a point where we get corner cases or business exceptions, and the question starts to arise, what shall we do? Is it worth the effort to invest in building a solution for this, or can we leave this function out of the system because it is not worth it? To answer this question, we want, if possible, feedback from the system to know this. We can quickly get this feedback making it explicit in the form of a Domain Event during our EventStorming and start monitoring it. This way we can leave the options open until we know what to do.

(more…)