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…)
with EventStorming and Example Mapping
This article was published in the leanpub book: Domain-Driven Design: The First 15 Years
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…)
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.
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 these 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.
Arranging a wedding is an exciting time to look forward to, but also comes with a lot of stress, especially when planning for it. For most of us, it will be the first time to plan our wedding, and, at least for me, hopefully, also the last. We can, of course, always hire a party planner (sort of like the domain expert on weddings), but getting married is already expensive enough, and for most of us this is not an option. Besides, there is also the family wishes to take in consideration, and might it just be that sometimes our family can also be domain experts. Let’s face it, they already seen there fair share of weddings, and most of them already have experience getting married themselves. We should consider their wishes and especially take advantage of their knowledge. Well, we can, with EventStorming! (and yes, I am the bridezilla of the two).
Technical design decision can have a severe impact on companies their communication structure. Conway’s law explains; “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” Such is the story also with a microservices architecture. A lot of companies decide to use REST to communicate between bounded contexts and or services. What can happens is that the services in the bounded context now get dependent on each other. The dependency on finishing a service their process will resolve in cascading failures if a service is down. Cascading failures will reflect on the way organizations communicate between teams. Teams now rely on each other before finishing their process. Dependency between teams can severely disrupt the company to respond better to the fast-changing demands of customers; companies get more entangled than before. To combat getting cascading failures, we must follow the communication structure of the business. We can do this by using Event Storming and going events-first.