From a Storm to Order – Part I
In this first article in a multi-series post, Consultant Tim Oleson discuss Domain-Driven Design and EventStorming.
The biggest challenge that we face as developers is understanding the problem that we’re trying to solve, understanding the business logic that we’re trying to implement inside of our code. In my opinion, this challenge has been one of the most significant issues we deal with as software designers and developers. Throughout my career, I have seen the biggest hurdle we face in software development and system design; is effective communication as engineers and architects. We need to be able to communicate effectively with businesspeople. Don’t get me wrong; some teams are effective in communicating, designing, and delivering successful architectures and systems to their clients, or to the business they support. Indeed, these are the folks that we should try to emulate in our day-to-day process and approaches to achieving successful architectural designs and systems that meet the needs of the business and align with their strategy.
In today’s Agile working environment, we need to be able to understand the problem space quickly. The ability to arrive at a deeper understanding in the least amount of time is vital when you’re working in a high speed two week sprints to understand the problem space that we’re trying to solve for the business. We need to be able to effectively communicate with the business experts, stakeholders, and subject matter experts (SEM). Although, we have many different methods, tools and processes that we can use to communicate with the business experts, tools like use cases, concrete scenarios, diagrams and flow charts they sometimes don’t wholly facilitate productive communication session, meaning they don’t drive out missing insights and greater understanding that we need, however when we combined these tools with effect methods, like Event Storms they can greatly assist us in our journey to understand and acquire knowledge of a business domain or business function. Consequently, we need to have a dialogue, a knowledge crunching session with the subject matter, experts of the given domain, and the functional business area. For example, an “Orders Domain” of an Online Shopping Site, as developers, we’re trying to solve problems or provide functionality that aligns with business that will help them achieve their strategic goals of producing money streams or reducing operating costs.
Eric Evans, introduced Domain-Driven Design to the greater Develop community in his book Domain-Driven Design: “Tackling Complexity in the Heart of Software 1st Edition”. In his book, he explains the first priority as developers, is to learn and speak the same language as the business. We, as developers, need to talk about the language of the business, and this language is what he calls the Ubiquitous language. Once we all are speaking the same language, then we will have less chance for ambiguity and misunderstanding that can produce a failure to meet the needs of the business or create bugs. In some cases, the bugs are not due to poor code, but poor understanding of the process, and you may be surprised to know that misunderstanding is sometimes derived from the business not being able to understand completely their own process, or business function as they may be overlooking some steps or details in this process. Now, I want to call out speaking as a critical component speaking out loud talking it through probing, the question of “why ” and not just the “how” need to be explored and discussed. Knowledge Crunching is a concept that Eric Evans talks about in his book, and is vital, and must be done up front and without being confused with upfront design, but as upfront conversation and understanding. So, we can translate that knowledge and understanding into a logical model, also known as “analysis model,” from which we create abstractions distilling down the problem space into a model which ultimately becomes the code model, and in Evan’s books ,the code is the truth. This is considered the strategic level, as opposed to where we as developers, love to live in the tactical space. The tactical space is the solution space, and it is essential to understand the differences between the Problem space(strategic) and the solution space(tactical). We must have a strategy in business, in war and in software, design this strategy drives or tactical design and patterns, and these tactical patterns are subordinate to the strategic model. As it is said, Abstractions should not depend on the details. Details should depend on the Abstractions, meaning the High-level modules should not depend on low-level modules. This “why” is that we need to have knowledge Crunch sessions with the domain experts, to drive out these Abstractions where the process is never a one and done , and the conversations should happen often as needed in cycles, and as the business changes, so will the model and so will the software and both the Strategic mode, and the solution tactical code model must be kept in sync with each other.
In the book Introducing EventStorming, an act of deliberate collective learning authored and created by Alberto Brandolini. Event Storming is a brainstorming session that we focus on the events of a business workflow or processes like OrderCreated would be an event in an Online Shopping Business workflow. EventStorming helps in building the Ubiquitous language of the business, which will ultimately end up reflected in the code Classes names, modules names, methods name properties, all will use the shared language of the business. This happens over a timeline from the beginning of the process, to the ending with the last Event that occurs in the workflow or business process.
The Right People
It is vital to have the right people in the room; four representatives from the development team and four representatives from the business subject matter experts, business analysis, stakeholders. The business people are the ones plotting the events, and a facilitator runs the show; his or her job is to keep everyone engaged, and Ontrack, development teams job is to question and challenge the business people.
This process is very approachable to businesspeople as it doesn’t use architecture or technology terms or UML. It only focuses on the business problem at hand and uses only the language of the business. How it is done is by clearing all of the chairs and tables from a room, ideally picking a room with a long wall and placing a long large piece of blotter paper on the wall, then the events are placed on the wall with Orange Post-It Notes. The event name is past tense and is written on the Post-it Notes using Sharpie markers. In the beginning, there are no wrong events as you want to encourage exploration and duplicates are ok for now, as we continue the conversation, we will remove events and move other events around based on insights and challenging questions. Other events trigger events, and they can fan out and back in one event can kick off two events that kick off another, and so on, we work our way down the timeline, regularly reading again over the events and validating all the events. As this process plays, deep learning and insight are achieved in a short amount of time.
After we have captured all the Events and grouped them and validated them will move on to:
– Plotting definitions and concerns
– Plotting commands
– Plotting external systems
– Plotting policies
– Plotting read-models
– Plotting aggregates
– Drawing boundaries
We will cover these topics in the next Blog Part II, Part III, and final wrap-up in Part IV of the series.