Breaking Apart a Complex Domain

One of the key problems when you are breaking a monolith are identifying the microservices and their respective domains. This is critical to get right otherwise you end up solving the wrong problem. How do we know which part of the monolith/megalith to attack first ? How does one identify the core domain and its supporting sub-domains.  

There are a couple of techniques that can serve as a launch point for this discovery. These techniques revolve around the idea of Visual Thinking i.e. mapping the domain as events or lego blocks and visualizing the data flow and system architecture. Three such techniques have emerged recently 1. Event Storming, 2. Visible Architecture and C-4 Model

Before breaking apart a complex domain its key to get a shared understanding of the current state of the domain. We need to establish a baseline where we label ALL the red flags and pain points of the system. Thereafter we move into problem solving and collaboration where we come up with solutions and approaches to move the system closer to our end-state, picking the features & approaches that give us the best chance of success. We need scientific techniques to break down a complex domain among a group of business and technical stakeholders. Fostering collaboration among people is a hard problem to solve. Event Storming and the Visible Architecture process outlined below, starts the conversation initiating the scientific process that leads to minimum viable microservices being carved from the monolith.

Event Storming

Event Storming is a group exercise to scientifically explore the domains and problem areas of a monolithic application. The most concise description of the process of event storming comes from Vaughn Vernon's DDD-Distilled book and the color around the process comes from Alberto Brandolini's book Event Storming. I have taken liberally from those two sources in this blog post. So how does one perform an exercise of event storming ?

1. Storm the business process by creating a series of Domain events on sticky notes. The most popular color to use for domain events is orange. The DomainEvent is a verb stated in past tense and represent a state transition in the domain. Write the name of the DomainEvent on an orange sticky note. Place the sticky notes on your modeling surface in time order from left to right. As you go through the storming session, you will find trouble spots in your existing business process. Clearly mark these with a purple/red stick notes. Use vertical space to represent parallel processing.

  src: Event Storming from Alberto Brandolini http://leanpub.com/introducing_eventstorming

2.  Create commands that cause each Domain Event. The command should be stated in the imperative. Place the light blue sticky note of the command left of the domain event that causes it. They are associated in pairs: Command/Event, Command/Event, ... If  there is a specific user role that performs an action and it is important to specify, place a small, bright yellow sticky note  on the lower left corner of the blue stickie. Sometimes a command can cause a Process to run. It is possible that creating commands will cause you to think about creating domain events. Place newly discovered events on the modeling surface along with the corresponding command. Sometimes one command may cause multiple events. Model that one command, and place it to the left of the multiple domain events. Once you have all commands associated with the domain events you are ready to move to the next step.

3. Associate the Entity/Aggregate on which the command is executed and that produces the Domain Event outcome. This is the data holder where commands are executed and domain events are executed. Other business friendly words for Aggregate are data or Entity.  Place the aggregate sticky behind the Command and domain event. If aggregates are repeatedly used then create the same aggregate noun on multiple sticky notes and place them repeatedly on the timeline where the corresponding Command/Event pairs occur. It is possible that as you think of data associated with the various actions you may discover more domain events. Never ignore new events, rather follow the same process as before to integrate the events with commands and aggregates.

4. Draw boundaries and lines with arrows to show flow on the modeling surface. You have discovered that there are multiple models in play and domain events flow between models. Use solid lines for  bounded contexts and dashed lines for subdomains. Draw lines with arrowheads to show direction of domain events flowing between bounded contexts. If you want to start bounding models with less permanence use ping stickies to mare general areas and withhold drawing boundaries with permanent markers till your confidence justifies it.

5. Identify the various views  that your users will need to carry out their actions, and important roles for various users. Use bright yellow stickies to identify user roles or personas.

An exercise in event storming may lead you to a CQRS Event Sourced architecture. If you pursue the path to using domain events as the system of record then leverage resources here to get deep into the world of Event Sourcing.

src: Event Storming from Alberto Brandolini http://leanpub.com/introducing_eventstorming

Visible Architecture:

src: Screenshot of Luke Hohmann's talk from Mucon

A visible architecture is a physical model of a system created by architecture teams using Duplo® bricks, with strings representing data flows. Visible architectures enable teams to collaboratively understand the “as-is” architecture and make better choices on the “to-be” architecture.

Quoting Luke ... 

The structured, yet creative freedom afforded by the technique enables teams to explore challenging concepts. For example, in one project, teams from Cisco represented known problems as “monsters” and outdated technologies as “dinosaurs” using plastic toys. In another project, teams from Rackspace used Visible Architectures as means to rapidly integrate acquired technologies.

Luke Hohmann has pioneered this technique and in this talk from Mucon, he presents an overview of the process, how to document desired changes in a structured manner, and how to augment Visible Architectures with powerful business frameworks that enable architects to "speak the business language" necessary to convert models into realities.

C-4 Model:

A software system is made up of one or more containers, each of which contains one or more components, which in turn are implemented by one or more classes. Some other techniques that I see of value in this space is the work done by Simon Brown in Modular Monoliths and the C-4 model. Checkout his book on Software Architecture for Developers. This book focusses on the visual communication and documentation of software architecture. The key facets of the software architecture are:

1. Context: A high-level diagram that sets the scene; including key system dependencies 

and people (actors/roles/personas/etc).

2. Container: A container diagram shows the high-level technology choices, how responsibilities are distributed across them and how the containers communicate.

3. Component: For each container, a component diagram lets you see the key logical components and their relationships.

4. Classes (or Code): Small number of high-level UML class diagrams  that explain how a particular pattern or component will be (or has been) implemented. 

These can be elicited from the code or drawn from scratch using tools like Structrizr