Software Architecture

Decision
We will use the component-based decomposition approach to migrate the existing monolithic Sysops Squad application to a distributed architecture.
The application has well-defined component boundaries, lending itself to the component-based decomposition approach.
This approach reduces the chance of having to maintain duplicate code within each service.
With the tactical forking approach, we would have to define the service boundaries up front to know how many forked applications to create. With the component-based decomposition approach, the service definitions will naturally emerge through component grouping.
Given the nature of the problems we are facing with the current application with regard to reliability, availability, scalability, and workflow, using the component-based decomposition approach provides a safer and more controlled incremental migration than the tactical forking approach does.
Consequences
The migration effort will likely take longer with the component-based decomposition approach than with tactical forking. However, we feel the justifications in the previous section outweigh this trade-off.
This approach allows the developers on the team to work collaboratively to identify shared functionality, component boundaries, and domain boundaries. Tactical forking would require us to break apart the team into smaller, separate teams for each forked application and increase the amount of coordination needed between the smaller teams.
Chapter 5. Component-Based Decomposition Patterns
Monday, November 1, 11:53
Addison and Austen chose to use the component-based decomposition approach, but were unsure about the details of each decomposition pattern. They tried to research this approach, but did not find much on the internet about it. Once again, they met with Logan in the conference room for advice on what these patterns are all about and how to use them.
“Listen, Logan,” said Addison, “I want to start out by saying we both really appreciate the amount of time you have been spending with us to get this migration process started. I know you’re super busy on your own firefights.”
“No problem,” said Logan. “Us firefighters have to stick together. I’ve been in your shoes before, so I know what it’s like flying blind on these sort of things. Besides, this is a highly visible migration effort, and it’s important you both get this thing right the first time. Because there won’t be a second time.”
“Thanks, Logan,” said Austen. “I’ve got a game in about two hours, so we’ll try to make this short. You talked earlier about component-based decomposition, and we chose that approach, but we aren’t able to find much about it on the internet.”
“I’m not surprised,” said Logan. “Not much has been written about them yet, but I know a book is coming out describing these patterns in detail sometime later this year. I first learned about these decomposition patterns at a conference about four years ago in a session with an experienced software architect. I was really impressed with the iterative and methodical approach to safely move from a monolithic architecture to a distributed one like service-based architecture and microservices. Since then I’ve been using these patterns with quite a bit of success.”
“Can you show us how these patterns work?” asked Addison.
“Sure,” said Logan. “Let’s take it one pattern at a time.”

Component-based decomposition (introduced in Chapter 4) is a highly effective technique for breaking apart a monolithic application when the codebase is somewhat structured and grouped by namespaces (or directories). This chapter introduces a set of patterns, known as component-based decomposition patterns, that describe the refactoring of monolithic source code to arrive at a set of well-defined components that can eventually become services. These decomposition patterns significantly ease the effort of migrating monolithic applications to distributed architectures.

Figure 5-1 shows the road map for the component-based decomposition patterns described in this chapter and how they are used together to break apart a monolithic application. Initially, these patterns are used together in sequence when moving a monolithic application to a distributed one, and then individually as maintenance is applied to the monolithic application during migration. These decomposition patterns are summarized as follows:
“Identify and Size Components Pattern”
Typically the first pattern applied when breaking apart a monolithic application. This pattern is used to identify, manage, and properly size components.
“Gather Common Domain Components Pattern”
Used to consolidate common business domain logic that might be duplicated across the application, reducing the number of potentially duplicate services in the resulting distributed architecture.
“Flatten Components Pattern”
Used to collapse or expand domains, subdomains, and components, thus ensuring that source code files reside only within well-defined components.
“Determine Component Dependencies Pattern”
Used to identify component dependencies, refine those dependencies, and determine the feasibility and overall level of effort for a migration from a monolithic architecture to a distributed one.
“Create Component Domains Pattern”
Used to group components into logical domains within the application and to refactor component namespaces and/or directories to align with a particular domain.
“Create Domain Services Pattern”
Used to physically break apart a monolithic architecture by moving logical domains within the monolithic application to separately deployed domain services.

Figure 5-1. Component-based decomposition pattern flow and usage

Each pattern described in this chapter is divided into three sections. The first section, “Pattern Description,” describes how the pattern works, why the pattern is important, and what the outcome is of applying the pattern. Knowing that most systems are moving targets during a migration, the second section, “Fitness Functions for Governance,” describes the automated governance that can be used after applying the pattern to continually analyze and verify the correctness of the codebase during ongoing maintenance. The third section uses the real-world Sysops Squad application (see “Introducing the Sysops Squad Saga”) to illustrate the use of the pattern and illustrate the transformations of the application after the pattern has been applied.