Domain Driven Design is getting a lot of attention in the architecture space, and why shouldn’t it? Making the focus of design on the business problem makes sense! Traditionally, we’ve had small groups of senior developers meet with an analyst, try to understand what the business problems are, and then dive deep into the technology to try to solve that problem. Unfortunately, some of the main outcomes are that the problem solved isn’t the one that’s needed to be solved, or it’s overly focused on the technology and the implementation of an idealist architecture that isn’t flexible enough to solve the problem. In both cases, the problems aren’t well resolved.
Enter Domain Driven Design (DDD), where the idea is to focus more strongly on the business, business process, and business problems. Some might argue that the architecture should be subordinate to those things. But, even with this newfound focus on the business, it’s been found that a lot of the problems are still overly focused on the technology at hand (if all I have is a hammer, everything’s a nail). Enter Brandolini’s Event Storming technique.
The Event Storming method is focused on first identifying the business process, and then building the architecture around that. The process is always at the center of the world in event storming, and everything hangs off that. Your business process becomes the bounded context. This is yet another reason that understanding the overall, cross-silo, business process is imperative. (for more on why you should care about Business Process Management, see this article) Once you understand the business process, you can start asking why things happen, how you know they happened, how you can test it, what happens if it doesn’t (again, good things to know in a BPM context too). These are your events. Hang these on the process model you’ve already put on the wall, make them part of the visual map.
If you read Brandolini’s work on Event Storming and how it’s morphed over the years, you’ll see that it’s begun to blend the ideas of multiple tools into one. You get user personas like in story-boarding, early identification of key tests from test-driven development, and all of this from a facilitated session similar to process discovery.
All of these ideas are important when building new software, not because they help create better code, but they do an excellent job of providing information for the team. It gives the entire team the context they need to effectively design and build a solution that will solve the business problems at hand. But, all of it needs to start with understanding how the business works.