Domain-Driven Design (DDD) has garnered attention within modern software architecture for the past seventeen years, and for good reason. Focusing your design around business problems makes sense. But many organizations make a simple mistake in adopting DDD: making assumptions about the right business problem to focus on. Below, we look at the importance of business process management as the foundation for good design, and dig deeper into one recommended technique for your process management.
Defining Domain-Driven Design
Traditionally, software architecture involved small groups of senior developers meeting with an analyst, trying to understand what the business problem was, and then diving deep into the technology to try and solve that problem. This approach was overly focused and reliant on the technology at hand, often resulting in the implementation of an idealist architecture that wasn’t flexible enough to solve problems. To borrow from Abraham Maslow’s analogy, if the only tool you have is a hammer, everything looks like a nail.
Enter DDD, first introduced in Eric Evan’s book Domain-Driven Design: Tackling Complexity in the Heart of Software. DDD proposes that we focus more on the business (aka the domain) and business problems, with some proponents arguing that the architecture should be subordinate to those things. At its core, DDD involves collaboration between developers and domain experts–your software’s customers or users–to address problems.
The Challenge: Identifying the Right Problem
DDD can fall short when a similarly collaborative approach isn’t taken to identifying the business problem (or problems) to focus on. Sometimes, teams employ this modern approach to design only to discover in the end that the issue they’ve solved for was not the organization’s most critical problem.
To address this challenge head on and create a strong foundation for DDD, understanding your overall, cross-silo business process is imperative. Your business process should become the bounded context. Knowing your business process means more than just knowing how someone in the warehouse packs a box. That’s an activity within a larger process–one that starts when a customer hits the checkout button on your website and continues until he or she receives the product. Processes span departments and encompass different areas of the company. Once you understand and map the current process, you can start to identify problems and opportunities to build a better one.
Enter Brandolini’s Event Storming Technique
How can a modern organization go about understanding its own process? Event Storming is a highly-creative, highly-visual technique for business process management that leverages cross-department collaboration to do exactly that. Plus, it’s holistic approach and principles of collaboration make it a good fit and foundation for Domain-Driven Design.
The Event Storming method, championed by Alberto Brandolini, is focused on first identifying the business process, and then building the architecture around it. Process is always at the center of the world in Event Storming, and everything hangs off of it. In Event Storming, you bring specialists from different areas together to ask why things happen, how to know they happened, how to test them, and what happens if they don’t go as intended. These are your events. You’ll hang these on the process model you’ve put on the wall and make them part of your 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. It involves user personas as with 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 for building modern software and microservices. They succeed not because they help us to create better code, but because they do an excellent job of providing information for teams. Together, Event Storming and Domain-Driven Design can give your entire team and third-party partners the context they need to effectively design and build a solution that will solve the business problems at hand. Starting with business process management and a shared understanding of how the business works ensures you’re focused on the right problems from the beginning.