Remote collaborative modelling part 1: Check-in

Collaborative modelling is not only an essential practice in Domain-Driven Design for creating a shared understanding of the domain. I believe it is vital in building sustainable and inclusive quality software. Covid-19 has constrained us to move collaborative modelling sessions online, and for almost everyone, this is uncharted territory and can be quite overwhelming. In these series of posts, I hope to give people some guidance and heuristics to start doing more of collaborative modelling in a remote world so that we can build more sustainable and inclusive quality software. We start this series with a practice that can make or break a collaborative modelling session, a Deep Democracy check-in.

(more…)

EventStorming; Core concepts, glossary and legend

Recently on Twitter Chris Richardson asked if anyone has created a consistent and comprehensive glossary for EventStorming core concepts.

I replied saying that #EventStorming is fuzzy by design. There are standard core concepts, and depending on the context, we use different words for the post-its. Because with that fuzziness, you get more insights. I call it just enough structure to let transactional conversations flow and create a shared mindset and tons of new insight—a shared pool of understanding. However thinking back at past workshops, and from skimming the EventStorming book checking out the core concepts, Chris has a point, we lack an excellent consistent glossary of the core concept, also specific per type. This post describes my take on EventStorming core concepts written down in a consistent and comprehensive glossary. Just be sure to try and avoid jargon as much as possible, as it sets up the unnecessary insider-outsider distinction.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet
(more…)

Making the most out of remote EventStorming

A while back the virtual Domain-driven design meetup experimented with doing a remote EventStorming. The outcome was that doing remote EventStorming as you would do it offline is sub-optimal. The interaction was lacking during the storming parts, and the number of insights gained was lower. That is the power of EventStorming, and it was not present. Still, we asked ourselves how we can make remote EventStorming more optimal, and with most of the world being stuck at home due to corona, I started experimenting with it. In this post, I will describe heuristics about my first experience with remote EventStorming.

EventStorming Workshop Facilitation | Avanscoperta
Copywrite: Avanscoperta
(more…)

Extending the Bounded Context Canvas with BDD Examples

Ever since Nick Tune introduced the world to the Bounded Context Canvas, I incorporate it in my workshops and trainings. Nick sees the canvas as a checklist for designing our Bounded Context canvas. For me, it is also perfect as a visualisation tool to make the Bounded Context explicit. The one thing I am missing is examples in the form of acceptance criteria discovered and eventually formalised during our Behaviour Driven Development flow. In this post, I explain how I extended the Bounded Context Canvas with BDD examples from Example Mapping to show how to formalise the behaviour of a Bounded Context.

(more…)

From EventStorming to CoDDDing

We live in a world of constant change. Today we generate more data than we can consume, and it contributes to the constant changes that we observe. Within the IT industry, we have the ambition to create flexible and reliable solutions that can cope with the demand for changes. We created frameworks, new programming languages, and abstracted the management of hardware with the cloud offering. Our industry provides tools and techniques that allow organizations to achieve the promised land of delivering business value to match the changing world. This is why we see many companies make a move towards microservices for mostly the same reasons; creating smaller deployable units, and to achieve a shorter and quicker feedback cycle. Moreover, many companies see the need for Domain-Driven Design to be able to do it.

To effectivly do Domain-driven design companies start to do EventStorming to help us to understand the domain better to design better microservices. However, EventStorming can be quite an overwhelming experience. Developers can be left with the question of how to turn a few stickies on a wall into working code.

Read João Rosa and mine Xpirit magazine #9 article to know how to go from EventStorming to coding.

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.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-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…)