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

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.

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.

By Paul de Raaij & Evelyn van Kelle

Software development is at the core of most companies. We’re all digital enterprises that need to understand how technology is heavily influencing our core business and can make or break our competitive advantage. Making the right decisions when it comes to investing in technology has become a crucial skill for digital leaders. 

“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. 

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

Read more →

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.

Read more →

Whenever I give or facilitate an EventStorming training or workshop people always ask me, what is inside your suitcase? What are the essential items I need to do a successful EventStorming? Most importantly what do I need to buy! So in this post, I will give you the EventStorming tools that are in my flight case and where you can buy it!

Read more →

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.

Read more →

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.

Read more →