The theory of domain driven design created by Eric Evans in his seminal book Domain Driven Design (
DDD) was published in August 30, 2003. Now DDD is such a dense tome that it requires an average senior software engineer two tries to read after which you wonder how exactly you apply this to running software. Thereafter you start reading the Vaughn Vernon's red
book - Implementing DDD to figure out the implementation of these patterns in code. At this point most software engineers are still struggling to apply the tactical and strategic patterns of domain driven design. This was the state of DDD around 2010.
Enter Adrian Cockcroft of Netflix fame who along with Martin Fowler sparked the microservices revolution and a renewed interest in DDD as the theoretical underpinning for microservices. This jazzed up everyone, since no one had a clue about how to structure the boundaries and domain for individual microservices. What is the correct way to design the boundaries of your services ? Bounded Contexts and sub-domains and context maps from DDD came to the rescue. and provided a basis to structure your system of microservices.
So we have the theory to now split and structure microservices. This again is NOT Enough. A lot of architects floundered in trying to figure out how to transform from a massive monolith to an event driven choreographed system of microservices. They struggled defining the subdomains and the bounded contexts.
Enter Alberto Brandolini who figured out that Event Storming is the only way that merges the people and technical aspects, the tactical and strategic aspects to visualize domains. Event Storming is a cross functional facilitation technique for revealing the bounded contexts, microservices, vertical Slices, trouble spots and starting points for a system or business process. Event Storming and other techniques that I mention later allowed architects and product owners to practice strategic DDD. There was no systematic way to practice strategic DDD to software before event storming. Alberto's influence on DDD in seminal as one who democratized it and made it available to masses. There is also an analogy to legos here. In the 1950's legos were introduced in Scandinavia, however their sales were struggling. Lego was far rom the powerhouse it was today. It is only when the Lego company started shipping instructions to build the lego sets, that sales took off. This is key - the packaging, the instructions that allowed a seven year old to build the set on their own and get a sense of accomplishment without nagging his/her parents.
Now having practiced event storming for a couple of years , we realized that incremental notation is key. If you get stuck on creating a color coordinated combination of aggregates, commands and events , read models, UI, data and policies it can pigeon hole and restrict the domain model and lead to a tunnel effect. Domain Events are front and center for event storming, everything else is secondary and needs to be added incrementally. The gap from event storming a system to an actual backlog of stories is HUGE. If you follow the textbook definitions of event storming you end up an event sourced CQRS system which most developers struggle to implement and maintain. A mistake i have lived with. There are multiple forms of event driven architecture and choreography
what-is-event-driven. We want to start with the easier incantations and then graduate to the top level of a full blown event sourced system.
This led to the
SWIFT method that leverages a technique called Boris that uses graph theory to model the relationships between the capabilities in a system. This process generates information about how the system "wants to be designed" and attempts to avoid pitfalls such as premature solutioning. At the end of a Boris Exercise, Services, APIs, Data and Event Choreography and a backlog of work starts becoming obvious.
After Boris it is critical to run multiple modeling exercises and then determine MVPs for the vertical flows. In order to determine the right MVPs for your system you have to consider thin vertical end to end slices where these domains interact with one another. You have to prioritize the thin slices based on technical effort, risk and business value. The slices encompass a sub section of events . The MVPs map a path from strangling the monolith and leveraging tactical patterns to interact with the new domains and services. There are multiple techniques that can be applied here including
domain story telling and user story
impact mapping.
Vertical slices are identified by choosing short, domain event flows in the core domain and defining the architectural components required to produce those events. Slice by slice, translate the domain model into microservices that use APIs, message queues, etc., that will run on the platform. Finally, a set of user stories is defined and mapped to releases or MVP.
After performing the mapping of user stories that realize the tactical patterns to MVPs, we now have a concrete backlog that developers can start with and iterate on.
Here is the full sequence of steps that help with decomposing a monolith:
1. Define Objectives and Key Results (OKR) for the app modernization effort.
2. Event storm the application and identify bounded contexts.
3. Pick several short domain event flows in the core domain that constitute a vertical slice.
4. Create Boris diagrams that define the relationships between the domains for an end to end slice
5. Perform SNAP analysis to score the effort and define data, API and messaging interfaces
6. Create a backlog of prioritize user stories tied back to OKR.
7. Impact Map user stories to MVP or releases.
At this point the benefits and promises of DDD become real and the theory of DDD laid out by Eric Evans becomes a pragmatic living software system.
Happy Modeling.
Rohit Kelapure
