Multiple models are in play on any large project. They emerge for many reasons. Two subsystems commonly serve very different user communities, with different jobs, where different models may be useful. Teams working independently may solve the same problem in different ways through lack of communication. The tool set may also be different, meaning that program code cannot be shared. Multiple models are inevitable, yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confused. It is often unclear in what context a model should not be applied. Model expressions, like any other phrase, only have meaning in context.Quote from DDD Reference, from Eric Evans However, by the nature of a Big Picture session, we start in a Chaotic Exploration mode, where the language is fuzzy, and boundaries (apparently) don’t exist. Thus, as a facilitator, I want to capture as many knowledge as people have, before given structure. After the Chaotic Exploration, the group enters into the phase known as Enforcing the Timeline. At this point, the group starts to discuss the events and builds a coherent story. Usually, at this point, the boundaries emerge, but not always. For those cases, it’s good to use some visual anchors, as scaffolding for further exploration. As example: It is useful for use cases, where the group (or organisation) is in a scale-up mode. Although there are some specialists in some parts of the process, the process doesn’t cross silos because they don’t exist! What I experienced is that this visual anchor helps the group to reason about parts of the process, enabling a discussion about the different boundaries within a process; it makes it easier to reason and discover those bounded contexts. What are your experiences when facilitating modelling sessions such as EventStorming? Any tips or clue?
One of the forms of EventStorming is Big Picture. It aims to convey the knowledge across different silos, capturing what’s in people’s minds. During a Big Picture session, it is normal to see Bounded Contexts emerging. Wait, what is a Bounded Context? Bounded Context is a strategic design pattern described by Eric Evans in his seminal book “Domain-Driven Design: Tackling Complexity in the Heart of Software“:This blog post is also in my personal blog.