Acknowledgments from Mark Richards

In addition to the preceding acknowledgments, I once again thank my lovely wife, Rebecca, for putting up with me through yet another book project. Your unending support and advice helped make this book happen, even when it meant taking time away from working on your own novel. You mean the world to me, Rebecca. I also thank my good friend and coauthor Neal Ford. Collaborating with you on the materials for this book (as well as our last one) was truly a valuable and rewarding experience. You are, and always will be, my friend.

Acknowledgments from Neal Ford

I would like to thank my extended family, Thoughtworks as a collective, and Rebecca Parsons and Martin Fowler as individual parts of it. Thoughtworks is an extraordinary group of people who manage to produce value for customers while keeping a keen eye toward why things work so that we can improve them. Thoughtworks supported this book in many ways and continues to grow Thoughtworkers who challenge and inspire me every day. I also thank our neighborhood cocktail club for a regular escape from routine, including the weekly outside, socially distanced versions that helped us all survive the odd time we just lived through. I thank my long-time friend Norman Zapien, who never ceases to provide enjoyable conversation. Lastly, I thank my wife, Candy, who continues to support this lifestyle that has me staring at things like book writing rather than our cats too much.

Acknowledgments from Pramod Sadalage

I thank my wife, Rupali, for all the support and understanding, and my lovely girls, Arula and Arhana, for the encouragement; daddy loves you both. All the work I do would not be possible without the clients I work with and various conferences that have helped me iterate on the concepts and content. I thank AvidXchange, the latest client I am working with, for its support and providing great space to iterate on new concepts. I also thank Thoughtworks for its continued support in my life, and Neal Ford, Rebecca Parsons, and Martin Fowler for being amazing mentors; you all make me a better person. Lastly, thank you to my parents, especially my mother, Shobha, whom I miss every day. I miss you, MOM.

Acknowledgments from Zhamak Dehghani

I thank Mark and Neal for their open invitation to contribute to this amazing body of work. My contribution to this book would not have been possible without the continuous support of my husband, Adrian, and patience of my daughter, Arianna. I love you both.

Any mechanism

Architects can use a wide variety of tools to implement fitness functions; we will show numerous examples throughout the book. For example, dedicated testing libraries exist to test architecture structure, architects can use monitors to test operational architecture characteristics such as performance or scalability, and chaos engineering frameworks test reliability and resiliency.

Objective integrity assessment

One key enabler for automated governance lies with objective definitions for architecture characteristics. For example, an architect can’t specify that they want a “high performance” website; they must provide an object value that can be measured by a test, monitor, or other fitness function.

Architects must watch out for composite architecture characteristics—ones

that aren’t objectively measurable but are really composites of other measurable things. For example, “agility” isn’t measurable, but if an architect starts pulling the broad term agility apart, the goal is for teams to be able to respond quickly and confidently to change, either in ecosystem or domain. Thus, an architect can find measurable characteristics that contribute to agility: deployability, testability, cycle time, and so on. Often, the lack of ability to measure an architecture characteristic indicates too vague a definition. If architects strive toward measurable properties, it allows them to automate fitness function application.

Some architecture characteristic or combination of architecture characteristics

This characteristic describes the two scopes for fitness functions:

Atomic

These fitness functions handle a single architecture characteristic in isolation.

For example, a fitness function that checks for component cycles within a codebase is atomic in scope.

Holistic

Holistic fitness functions validate a combination of

architecture characteristics. A complicating feature of architecture characteristics is the synergy they sometimes exhibit with other architecture characteristics. For example, if an architect wants to improve security, a good chance exists that it will affect performance. Similarly, scalability and elasticity are sometimes at odds—supporting a large number of concurrent users can make handling sudden bursts more difficult. Holistic fitness functions exercise a combination of interlocking architecture characteristics to ensure that the combined effect won’t negatively affect the architecture.

Figure 1-1. Cyclic dependencies between components

In this anti-pattern, each component references something in the others. Having a network of components such as this damages modularity because a developer cannot reuse a single component without also bringing the others along. And, of course, if the other components are coupled to other components, the architecture tends more and more toward the Big Ball of Mud anti-pattern. How can architects govern this behavior without constantly looking over the shoulders of trigger-happy developers? Code reviews help but happen too late in the development cycle to be effective. If an architect allows a development team to rampantly import across the codebase for a week until the code review, serious damage has already occurred in the codebase.

The solution to this problem is to write a fitness function to avoid component cycles, as shown in Example 1-1.

public class CycleTest { private JDepend jdepend; @BeforeEach void init() { jdepend = new JDepend(); jdepend.addDirectory("/path/to/project/persistence/classes"); jdepend.addDirectory("/path/to/project/web/classes"); jdepend.addDirectory("/path/to/project/thirdpartyjars"); } @Test void testAllPackages() { Collection packages = jdepend.analyze(); assertEquals("Cycles exist", false, jdepend.containsCycles()); } }

In the code, an architect uses the metrics tool JDepend to

Figure 1-2. Traditional layered architecture

However, how can the architect ensure that developers will respect these layers? Some developers may not understand the importance of the patterns, while others may adopt a “better to ask forgiveness than permission” attitude because of some overriding local concern, such as performance. But allowing implementers to erode the reasons for the architecture hurts the long-term health of the architecture.

ArchUnit allows architects to address this problem via a fitness function, shown in Example 1-2.

layeredArchitecture() .layer("Controller").definedBy("..controller..") .layer("Service").definedBy("..service..") .layer("Persistence").definedBy("..persistence..") .whereLayer("Controller").mayNotBeAccessedByAnyLayer() .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller") .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Service")

In Example 1-2, the architect defines the desirable relationship between layers and writes a verification fitness function to govern it. This allows an architect to establish architecture principles outside the diagrams and other informational artifacts, and verify them on an ongoing basis.

A similar tool in the .NET space,

// Classes in the presentation should not directly reference repositories var result = Types.InCurrentDomain() .That() .ResideInNamespace("NetArchTest.SampleLibrary.Presentation") .ShouldNot() .HaveDependencyOn("NetArchTest.SampleLibrary.Data") .GetResult() .IsSuccessful;

Tools continue to appear in this space with increasing degrees of sophistication. We will continue to highlight many of these techniques as we illustrate fitness functions alongside many of our solutions.

Finding an objective outcome for a fitness function is critical.

Figure 1-3. Components within the existing Sysops Squad application

These components will be used in subsequent chapters to illustrate various techniques and trade-offs when dealing with breaking applications into distributed architectures.

Sysops Squad Data Model

The Sysops Squad application with its various components listed in Table 1-1

Figure 1-4. Data model within the existing Sysops Squad application

The Sysops data model is a standard third normal form data model with only a few stored procedures or triggers. However, a fair number of views exist that are mainly used by the Reporting component. As the architecture team tries to break up the application and move toward distributed architecture, it will have to work with the database team to accomplish the tasks at the database level. This setup of database tables and views will be used throughout the book to discuss various techniques and trade-offs to accomplish the task of breaking apart the database.

Third, independent deployability forces the architecture quantum to include common coupling points such as databases. Most discussions about architecture conveniently ignore issues such as databases and user interfaces, but real-world systems must commonly deal with those problems. Thus, any system that uses a shared database fails the architecture quantum criteria for independent deployment unless the database deployment is in lockstep with the application. Many distributed systems that would otherwise qualify for multiple quanta fail the independently deployable part if they share a common database that has its own deployment cadence. Thus, merely considering the deployment boundaries doesn’t solely provide a useful measure. Architects should also consider the second criteria for an architecture quantum, high functional cohesion, to limit the architecture quantum to a useful scope.

High Functional Cohesion

High functional cohesion refers structurally to the proximity

An architecture quantum is, in part, a measure of static coupling, and the measure is quite simple for most architecture topologies. For example, the following diagrams show the architecture styles featured in Fundamentals of Software Architecture, with the architecture quantum static coupling illustrated.

Any of the monolithic architecture styles will necessarily have a

Figure 2-2. Monolithic architectures always have a quantum of one

As you can see, any architecture that deploys as a single unit and utilizes a single database will always have a single quantum. The architecture quantum measure of static coupling includes the database, and a system that relies on a single database cannot have more than a single quantum. Thus, the static coupling measure of an architecture quantum helps identify coupling points in architecture, not just within the software components under development. Most monolithic architectures contain a single coupling point (typically, a database) that makes its quantum measure one.

Distributed architectures often feature decoupling at the component level;

Figure 2-3. Architecture quantum for a service-based architecture

While this individual services model shows the isolation common in microservices, the architecture still utilizes a single relational database, rendering its architecture quantum score to one.

So far, the static coupling measurement of architecture quantum has evaluated all the topologies to one. However, distributed architectures create the possibility of multiple quanta but don’t necessarily guarantee it.

Even though this style represents a distributed architecture, two coupling points push it toward a single architecture quantum: the database, as common with the previous monolithic architectures, but also the Request Orchestrator itself—any holistic coupling point necessary for the architecture to function forms an architecture quantum around it.

Figure 2-4. A mediated EDA has a single architecture quantum

Broker event-driven architectures (without a central mediator) are less coupled,

This broker-style event driven architecture (without a central mediator) is nevertheless a single architecture quantum because all the services utilize a single relational database, which acts as a common coupling point. The question answered by the static analysis for an architecture quantum is, “Is this dependent of the architecture necessary to bootstrap this service?” Even in the case of an event-driven architecture where some of the services don’t access the database, if they rely on services that do access the database, then they become part of the static coupling of the architecture quantum.

Figure 2-5. Even a distributed architecture such as broker-style event-driven architecture can be a single quantum

However, what about situations in distributed architectures where common coupling points don’t exist?

The architects designed this event-driven system

Figure 2-6. An event-driven architecture with multiple quanta

The microservices architecture style features

Figure 2-7. Microservices may form their own quanta

Each service (acting as a bounded context) may have its own set of architecture characteristics—one service might have higher levels of scalability or security than another. This granular level of architecture characteristics scoping represents one of the advantages of the microservices architecture style. High degrees of decoupling allow teams working on a service to move as quickly as possible, without worrying about breaking other dependencies.

However, if the system is tightly coupled to a user interface,

Figure 2-8. A tightly coupled user interface can reduce a microservices architecture quantum to one

User interfaces create coupling points between the front and back end, and most user interfaces won’t operate if portions of the backend aren’t available.

Additionally, it will be difficult for an architect to design different levels of operational architecture characteristics (performance, scale, elasticity, reliability, and so on) for each service if they all must cooperate together in a single user interface (particularly in the case of synchronous calls, covered in “Dynamic Quantum Coupling”).

Architects design user interfaces utilizing asynchronicity that doesn’t create coupling between front and back. A trend on many microservices projects is to use a micro frontend framework for user interface elements in a microservices architecture. In such an architecture, the user interface elements that interact on behalf of the services are emitted from the services themselves. The user interface surface acts as a canvas where the user interface elements can appear, and also facilitates loosely coupled communication between components, typically using events. Such an architecture is illustrated in Figure 2-9.

Figure 2-9. In a micro-frontend architecture, each service + user interface component forms an architecture quantum

In this example, the four tinted services along with their corresponding micro-frontends form architecture quanta: each of these services may have different architecture characteristics.

Any coupling point in an architecture can create static coupling points from a quantum standpoint. Consider the impact of a shared database between two systems, as illustrated in Figure 2-10.

The static coupling of a system provides valuable insight, even in complex systems involving integration architecture. Increasingly, a common architect technique for understanding legacy architecture involves creating a static quantum diagram of how things are “wired” together, which helps determine what systems will be impacted by change and offers a way of understanding (and potentially decoupling) the architecture.

Static coupling is only one-half of the forces at play in distributed architectures. The other is dynamic coupling.

Figure 2-10. A shared database forms a coupling point between two systems, creating a single quantum

Maintainability

Maintainability is about the ease of adding, changing, or removing features,

where ML is the maintainability level of the overall system (percentage from 0% to 100%), k is the total number of logical components in the system, and c_i is the coupling level for any given component, with a special focus on incoming coupling levels. This equation basically demonstrates that the higher the incoming coupling level between components, the lower the overall maintainability level of the codebase.

Putting aside complicated mathematics, some of the typical metrics used for determining the relative maintainability of an application based on components (the architectural building blocks of an application) include the following:

Component coupling

The degree and manner to which components know about one another

Component cohesion

The degree and manner to which the operations of a component interrelate

Cyclomatic complexity

The overall level of indirection and nesting within a component

Component size

The number of aggregated statements of code within a component

Technical versus domain partitioning

Components aligned by technical usage or by domain

purpose—see

Appendix A

Within the context of architecture, we are

Figure 3-4. With monolithic layered architectures, change is at an application level

Depending on the team structure, implementing this simple change to add an expiration date to wish list items in a monolithic layered architecture could possibly require the coordination of at least three teams:

• A member from the user interface team would be needed to add the new expiry field to the screen.

• A member from the backend team would be needed to add business rules associated with the expiry date and change contracts to add the new expiry field.

• A member from the database team would be needed to change the table schema to add the new expiry column in the Wishlist table.

Since the Wishlist domain is spread throughout the entire architecture, it becomes harder to maintain a particular domain or subdomain (such as Wishlist). Modular architectures, on the other hand, partition domains and subdomains into smaller, separately deployed units of software, thereby making it easier to modify a domain or subdomain. Notice that with a distributed service-based architecture, as shown in Figure 3-5, the change scope of the new requirement is at a domain level within a particular domain service, making it easier to isolate the specific deployment unit requiring the change.

Moving to even more architectural modularity

Figure 3-5. With service-based architectures, change is at a domain level

Figure 3-6. With microservices architectures, change is at a function level

These three progressions toward modularity demonstrate that as the level of architectural modularity increases, so does maintainability, making it easier to add, change, or remove functionality.

Making a change to Service A limits the testing scope to only that service, since Service B and Service C are not coupled to Service A. However, as communication increases among these services, as shown at the bottom of Figure 3-7, testability declines rapidly because the testing scope for a change to Service A now includes Service B and Service C, therefore impacting both the ease of testing and the completeness of testing.

Figure 3-7. Testing scope is increased as services communicate with one another

Deployability

Deployability is not only about the ease of deployment—it is also about

If your microservices must be deployed as a complete set in a specific order, please put them back in a monolith and save yourself some pain.

This scenario leads to what is commonly referred to as the “big ball of distributed mud,” where very few (if any) of the benefits of architectural modularity are realized.

Scalability

Scalability is defined as the ability of a system to remain

Figure 3-8. Scalability is different from elasticity

While both of these architectural characteristics include responsiveness as a function of the number of concurrent requests (or users in the system), they are handled differently from an architectural and implementation standpoint. Scalability generally occurs over a longer period of time as a function of normal company growth, whereas elasticity is the immediate response to a spike in user load.

A great example to further illustrate the difference is that of a concert-ticketing system. Between major concert events, there is usually a fairly light concurrent user load. However, the minute tickets go on sale for a popular concert, concurrent user load significantly spikes. The system may go from 20 concurrent users to 3,000 concurrent users in a matter of seconds. To maintain responsiveness, the system must have the capacity to handle the high peaks in user load, and also have the ability to instantaneously start up additional services to handle the spike in traffic.

Notice that scalability and elasticity rate relatively low with the monolithic layered architecture. Large monolithic layered architectures are both difficult and expensive to scale because all of the application functionality must scale to the same degree (application-level scalability and poor MTTS). This can become particularly costly in cloud-based infrastructures.

Figure 3-9. Scalability and elasticity improve with modularity

Afferent and Efferent Coupling

In 1979, Edward Yourdon and Larry Constantine published

In this example, the Eclipse plug-in provides

Figure 4-2. JDepend in Eclipse analysis view of coupling relationships

In the equation, $m^a$ represents abstract elements (interfaces or abstract classes) within the codebase, and $m^c$ represents concrete elements. Architects calculate abstractness by calculating the ratio of the sum of abstract artifacts to the sum of the concrete ones.

Another derived metric, instability, is the

In the equation, $C^e$ represents efferent (or outgoing)

In the equation, A = abstractness and I = instability.

The distance-from-the-main-sequence metric imagines an ideal relationship between abstractness and instability; components that fall near this idealized line exhibit a healthy mixture of these two competing concerns. For example, graphing a particular component allows developers to calculate the distance-from-the-main-sequence metric, illustrated in Figure 4-3.

Figure 4-3. Normalized distance from the main sequence for a particular component

Developers graph the candidate component, then measure the distance from the idealized line. The closer to the line, the better balanced the component.

Tools exist in many platforms to provide these measures, which assist architects when analyzing codebases because of unfamiliarity, migration, or technical debt assessment.

What does the distance-from-the-main-sequence metric tell architects looking to restructure applications? Just as in construction projects, moving a large structure that has a poor foundation presents risks. Similarly, if an architect aspires to restructure an application, improving the internal structure will make it easier to move the entity.

Figure 4-4. Zones of uselessness and pain

This metric also provides a good clue as to the balance of the internal structure. If an architect evaluates a codebase where many of the components fall into either the zones of uselessness or pain, perhaps it is not a good use of time to try to shore up the internal structure to the point where it can be repaired.

Following the flowchart in Figure 4-1, once an architect decides that the codebase is decomposable, the next step is to determine what approach to take to decompose the application. The following sections describe the two approaches for decomposing an application: component-based decomposition and tactical forking.

Trade-Offs

Tactical forking is a viable alternative to a more formal

Component name

A descriptive name and identifier of the component that is

consistent throughout application diagrams and documentation. The component name should be clear enough to be as self-describing as possible. For example, the component Billing History shown in

Table 5-1 is clearly a component that contains source code files used to manage a customer’s billing history. If the distinct role and responsibility of the component isn’t immediately identifiable, consider changing the component (and potentially the corresponding namespace) to a more descriptive one. For example, a component named Ticket Manager leaves too many unanswered questions about its role and responsibility in the system, and should be renamed to better describe its role.

Component namespace

The physical (or logical) identification of the component representing where the

source code files implementing that component are grouped and stored. This identifier is usually denoted through a namespace, package structure (Java), or directory structure. When a directory structure is used to denote the component, we usually convert the file separator to a dot (.) and create a corresponding logical namespace. For example, the component namespace for source code files in the ss/customer/notification directory structure would have the namespace value ss.customer.notification. Some languages require that the namespace match the directory structure (such as Java with a package), whereas other languages (such as C# with a namespace) do not enforce this constraint. Whatever namespace identifier is used, make sure the type of identifier is consistent across all of the components in the application.

Percent

The relative size of the component based on its percentage of the overall source code containing that component. The percent metric is helpful in identifying components that appear too large or too small in the overall application. This metric is calculated by taking the total number of statements within the source code files representing that component and dividing that number by the total number of statements in the entire codebase of the application. For example, the percent value of 5 for the ss.billing.payment component in

Table 5-1 means that this component constitutes 5% of the overall codebase.

Statements

The sum of the total number of source code statements in all source files contained within that component. This metric is useful for determining not only the relative size of the components within an application, but also for determining the overall complexity of the component. For example, a seemingly simple single-purpose component named Customer Wishlist might have a total of 12,000 statements, indicating that the processing of wish list items is perhaps more complex than it looks. This metric is also necessary for calculating the percent metric previously described.

Files

The total number of source code files (such as classes, interfaces, types, and so on) that are contained within the component. While this metric has little to do with the size of a component, it does provide additional information about the component from a class structure standpoint. For example, a component with 18,409 statements and only 2 files is a good candidate for refactoring into smaller, more contextual classes.

When resizing a large component, we recommend using a functional decomposition approach or a domain-driven approach to identify subdomains that might exist within the large component. For example, assume the Sysops Squad application has a Trouble Ticket component containing 22% of the codebase that is responsible for ticket creation, assignment, routing, and completion. In this case, it might make sense to break the single Trouble Ticket component into four separate components (Ticket Creation, Ticket Assignment, Ticket Routing, and Ticket Completion), reducing the percentage of code each component represents, therefore creating a more modular application. If no clear subdomains exist within a large component, then leave the component as is.

Fitness Functions for Governance

Once this decomposition pattern has been applied and components

# Get prior component namespaces that are stored in a datastore LIST prior_list = read_from_datastore() # Walk the directory structure, creating namespaces for each complete path LIST current_list = identify_components(root_directory) # Send an alert if new or removed components are identified LIST added_list = find_added(current_list, prior_list) LIST removed_list = find_removed(current_list, prior_list) IF added_list NOT EMPTY { add_to_datastore(added_list) send_alert(added_list) } IF removed_list NOT EMPTY { remove_from_datastore(removed_list) send_alert(removed_list) }

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Walk through all of the source code to accumulate total statements total_statements = accumulate_statements(root_directory) # Walk through the source code for each component, accumulating statements # and calculating the percentage of code each component represents. Send # an alert if greater than 10% FOREACH component IN component_list { component_statements = accumulate_statements(component) percent = component_statements / total_statements IF percent > .10 { send_alert(component, percent) } }

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Walk through all of the source code to accumulate total statements and number # of statements per component SET total_statements TO 0 MAP component_size_map FOREACH component IN component_list { num_statements = accumulate_statements(component) ADD num_statements TO total_statements ADD component,num_statements TO component_size_map } # Calculate the standard deviation SET square_diff_sum TO 0 num_components = get_num_entries(component_list) mean = total_statements / num_components FOREACH component,size IN component_size_map { diff = size - mean ADD square(diff) TO square_diff_sum } std_dev = square_root(square_diff_sum / (num_components - 1)) # For each component calculate the number of standard deviations from the # mean. Send an alert if greater than 3 FOREACH component,size IN component_size_map { diff_from_mean = absolute_value(size - mean); num_std_devs = diff_from_mean / std_dev IF num_std_devs > 3 { send_alert(component, num_std_devs) } }

Addison noticed that most of the components listed in Table 5-2 are about the same size, with the exception of the Reporting component (ss.reporting) which consisted of 33% of the codebase. Since the Reporting component was significantly larger than the other components (illustrated in Figure 5-2), Addison chose to break this component apart to reduce its overall size.

Figure 5-2. The Reporting component is too big and should be broken apart

After doing some analysis, Addison found that the reporting component contained source code that implemented three categories of reports:

• Ticketing reports (ticket demographics reports, tickets per day/week/month reports, ticket resolution time reports, and so on)

• Expert reports (expert utilization reports, expert distribution reports, and so on)

• Financial reports (repair cost reports, expert cost reports, profit reports, and so on)

Addison also identified common (shared) code that all reporting categories used, such as common utilities, calculators, shared data queries, report distribution, and shared data formatters. Addison created an architecture story (see “Architecture Stories”) for this refactoring and explained it to the development team. Sydney, one of the Sysops Squad developers assigned the architecture story, refactored the code to break apart the single Reporting component into four separate components—a Reporting Shared component containing the common code and three other components (Ticket Reports, Expert Reports, and Financial Reports), each representing a functional reporting area, as illustrated in Figure 5-3.

Figure 5-3. The large Reporting component broken into smaller reporting components

After Sydney committed the changes, Addison reanalyzed the code and verified that all of the components were now fairly equally distributed in size. Addison recorded the results of applying this decomposition pattern in Table 5-3.

Notice in the preceding Sysops Squad Saga that Reporting no longer exists as a component in Table 5-3 or Figure 5-3. Although the namespace still exists (ss.reporting), it is no longer considered a component, but rather a subdomain.

Another way of identifying common domain functionality is through the name of a logical component or its corresponding namespace. Consider the following components (represented as namespaces) in a large codebase:

• Ticket Auditing (penultimate.ss.ticket.audit)

• Billing Auditing (penultimate.ss.billing.audit)

• Survey Auditing (penultimate.ss.survey.audit)

Notice how each of these components (Ticket Auditing, Billing Auditing, and Survey Auditing) all have the same thing in common—writing the action performed and the user requesting the action to an audit table. While the context may be different, the final outcome is the same—inserting a row in an audit table. This common domain functionality can be consolidated into a new component called penultimate.ss.shared.audit, resulting in less duplication of code and also fewer services in the resulting distributed architecture.

Not all common domain functionality necessarily becomes a shared service. Alternatively, common code could be gathered into a shared library that is bound to the code during compile time. The pros and cons of using a shared service rather than a shared library are discussed in detail in Chapter 8.

Fitness Functions for Governance

Automating the governance of shared domain functionality

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Locate possible duplicate component node names that are not in the exclusion # list stored in a datastore LIST excluded_leaf_node_list = read_datastore() LIST leaf_node_list LIST common_component_list FOREACH component IN component_list { leaf_name = get_last_node(component) IF leaf_name IN leaf_node_list AND leaf_name NOT IN excluded_leaf_node_list { ADD component TO common_component_list } ELSE { ADD leaf_name TO leaf_node_list } } # Send an alert if any possible common components were found IF common_component_list NOT EMPTY { send_alert(common_component_list) }

# Walk the directory structure, creating namespaces for each complete path and a list # of source file names for each component LIST component_list = identify_components(root_directory) LIST source_file_list = get_source_files(root_directory) MAP component_source_file_map FOREACH component IN component_list { LIST component_source_file_list = get_source_files(component) ADD component, component_source_file_list TO component_source_file_map } # Locate possible common source file usage across components that are not in # the exclusion list stored in a datastore LIST excluded_source_file_list = read_datastore() LIST common_source_file_list FOREACH source_file IN source_file_list { SET count TO 0 FOREACH component,component_source_file_list IN component_source_file_map { IF source_file IN component_source_file_list { ADD 1 TO count } } IF count > 1 AND source_file NOT IN excluded_source_file_list { ADD source_file TO common_source_file_list } } # Send an alert if any source files are used in multiple components IF common_source_file_list NOT EMPTY { send_alert(common_source_file_list) }

While each of these notification components had a different context for notifying a customer, Addison realized they all have one thing in common—they all sent information to a customer. Figure 5-4 illustrates these common notification components within the Sysops Squad application.

Noticing that the source code contained in these components was also very similar, Addison consulted with Austen (the other Sysops Squad architect). Austen liked the idea of a single notification component, but was concerned about impacting the overall level of coupling between components. Addison agreed that this might be an issue and investigated this trade-off further.

Figure 5-4. Notification functionality is duplicated throughout the application

Addison analyzed the incoming (afferent) coupling level for the existing Sysops Squad notification components and came up with the resulting coupling metrics listed in Table 5-5, with “CA” representing the number of other components requiring that component (afferent coupling).

Addison then found that if the customer notification functionality was consolidated into a single component, the coupling level for the resulting single component increased to an incoming coupling level of 5, as shown in Table 5-6.

Addison brought these findings to Austen, and they discussed the results. What they found is that, while the new consolidated component had a fairly high level of incoming coupling, it didn’t affect the overall afferent (incoming) coupling level for notifying a customer. In other words, the three separate components had a total incoming coupling level of 5, but so did the single consolidated component.

Addison and Austen both realized how important it was to

Figure 5-5. Notification functionality is consolidated into a new single component called Notification

Table 5-7 shows the resulting components after Sydney implemented the architecture story Addison created. Notice that the Customer Notification component (ss.customer.notification), Ticket Notify component (ss.ticket.notify), and Survey Notify components (ss.survey.notify) were removed, and the source code moved to the new consolidated Notification component ( ss.notification).

While this structure might seem to make sense from a developer’s standpoint in order to keep the template code separate from survey processing, it does create some problems because Survey Templates, as a component, would be considered part of the Survey component. One might be tempted to consider Survey Templates as a subcomponent of Survey, but then issues arise when trying to form services from these components—should both components reside in a single service called Survey, or should the Survey Templates be a separate service from the Survey service?

We’ve resolved this dilemma by defining a component as the last node (or leaf node) of the namespace or directory structure. With this definition, ss.survey.templates is a component, whereas ss.survey would be considered a subdomain, not a component. We further define namespaces such as ss.survey as root namespaces because they are extended with other namespace nodes (in this case, .templates).

Notice how the ss.survey root namespace in Table 5-8 contains five class files. We call these class files orphaned classes because they do not belong to any definable component. Recall that a component is identified by a leaf node namespace containing source code. Because the ss.survey namespace was extended to include .templates, ss.survey is no longer considered a component and therefore should not contain any class files.

The following terms and corresponding definitions are important for understanding and applying the Flatten Components decomposition pattern:

Component

A collection of classes grouped

within a leaf node namespace that performs some sort of specific functionality in the application (such as payment processing or customer survey functionality).

Root namespace

A namespace node that has been extended by another

namespace node. For example, given the namespaces ss.survey and ss.survey.templates, ss.survey would be considered a root namespace because it is extended by .templates. Root namespaces are also sometimes referred to as subdomains.

Orphaned classes

Classes contained within a root namespace, and hence have no definable component associated with them.

Figure 5-6. Components, root namespaces, and orphaned classes (C box denotes source code)

Notice that since both ss.survey and ss.ticket are extended through other namespace nodes, those namespaces are considered root namespaces, and the classes contained in those root namespaces are hence orphaned classes (belonging to no defined component). Thus, the only components denoted in Figure 5-6 are ss.survey.templates, ss.login, ss.ticket.assign, and ss.ticket.route.

The Flatten Components decomposition pattern is used to move orphaned classes to create well-defined components that exist only as leaf nodes of a directory or namespace, creating well-defined subdomains (root namespaces) in the process. We refer to the flattening of components as the breaking down (or building up) of namespaces within an application to remove orphaned classes. For example, one way of flattening the ss.survey root namespace in Figure 5-6 and remove orphaned classes is to move the source code contained in the ss.survey.templates namespace down to the ss.survey namespace, thereby making ss.survey a single component (.survey is now the leaf node of that namespace). This flattening option is illustrated in Figure 5-7.

Figure 5-7. Survey is flattened by moving the survey template code into the .survey namespace

Alternatively, flattening could also be applied by taking the source code in ss.survey and applying functional decomposition or domain-driven design to identify separate functional areas within the root namespace, thus forming components from those functional areas. For example, suppose the functionality within the ss.survey namespace creates and sends a survey to a customer, and then processes a completed survey received from the customer. Two components could be created from the ss.survey namespace: ss.survey.create, which creates and sends the survey, and ss.survey.process, which processes a survey received from a customer. This form of flattening is illustrated in Figure 5-8.

Figure 5-8. Survey is flattened by moving the orphaned classes to new leaf nodes ( components)

Tip

Regardless of the direction of flattening, make sure source code files reside only in leaf node namespaces or directories so that source code can always be identified within a specific component.

Another common scenario where orphaned source code might reside in a root namespace is when code is shared by other components within that namespace. Consider the example in Figure 5-9 where customer survey functionality resides in three components (ss.survey.templates, ss.survey.create, and ss.survey.process), but common code (such as interfaces, abstract classes, common utilities) resides in the root namespace ss.survey.

Figure 5-9. Shared code in .survey is considered orphaned classes and should be moved

The shared classes in ss.survey would still be considered orphaned classes, even though they represent shared code. Applying the Flatten Components pattern would move those shared orphaned classes to a new component called ss.survey.shared, therefore removing all orphaned classes from the ss.survey subdomain, as illustrated in Figure 5-10.

Figure 5-10. Shared survey code is moved into its own component

Our advice when moving shared code to a separate component (leaf node namespace)

Figure 5-11. The Survey and Ticket components contain orphaned classes and should be flattened

Addison decided to address the ticketing components first. Knowing that flattening components meant getting rid of source code in nonleaf nodes, Addison had two choices: consolidate the code contained in the ticket assignment and ticket routing components into the ss.ticket component, or break up the 45 classes in the ss.ticket component into separate components, thus making ss.ticket a subdomain. Addison discussed these options with Sydney (one of the Sysops Squad developers), and based on the complexity and frequent changes in the ticket assignment functionality, decided to keep those components separate and move the orphaned code from the ss.ticket root namespace into other namespaces, thus forming new components.

With help from Sydney, Addison found that the 45 orphaned classes contained in the ss.ticket namespace implemented the following ticketing functionality:

• Ticket creation and maintenance (creating a ticket, updating a ticket, canceling a ticket, etc.)

• Ticket completion logic

• Shared code common to most of the ticketing functionality

Since ticket assignment and ticket routing functionality were already in their own components (ss.ticket.assign and ss.ticket.route, respectively), Addison created an architecture story to move the source code contained in the ss.ticket namespace to three new components, as shown in Table 5-10.

Addison then considered the survey functionality. Working with Sydney, Addison found that the survey functionality rarely changed and was not overly complicated. Sydney talked with Skyler, the Sysops Squad developer who originally created the ss.survey.templates namespace, and found there was no compelling reason to separate the survey templates into their own namespace (“It just seemed like a good idea at the time,” said Skyler). With this information, Addison created an architecture story to move the seven class files from ss.survey.templates into the ss.survey namespace and removed the ss.survey.template component, as shown in Table 5-11.

After applying the Flatten Components pattern (illustrated in Figure 5-12), Addison observed that there were no “hills” (component upon component) or orphaned classes and that all of the components were contained only in the leaf nodes of the corresponding namespace.

Figure 5-12. The Survey component was flattened into a single component, whereas the Ticket component was raised up and flattened, creating a Ticket subdomain

Addison recorded the results of the refactoring efforts thus far in applying these decomposition patterns and listed them in Table 5-12.

It’s important to note that this pattern is about component dependencies, not individual class dependencies within a component. A component dependency is formed when a class from one component (namespace) interacts with a class from another component (namespace). For example, suppose the CustomerSurvey class in the ss.survey component invokes a method in the CustomerNotification class in the ss.notification component to send out the customer survey, as illustrated in the pseudocode in Example 5-7.

namespace ss.survey class CustomerSurvey { function createSurvey { ... } function sendSurvey { ... ss.notification.CustomerNotification.send(customer_id, survey) } }

Notice the dependency between the Survey and Notification components, because the CustomerNotification class used by the CustomerSurvey class resides outside the ss.survey namespace. Specifically, the Survey component would have an efferent (or outgoing) dependency on the Notification component, and the Notification component would have an afferent (or incoming) dependency on the Survey component.

Note that the classes within a particular component may be a highly coupled mess of numerous dependencies, but that doesn’t matter when applying this pattern—what matters is only those dependencies between components.

Several tools are

Figure 5-13. A monolithic application with minimal component dependencies takes less effort to break apart (golf ball sizing)

With a dependency diagram like Figure 5-13, the answers to the three key questions are as follows:

1. Is it feasible to break apart the existing monolithic application? Yes

2. What is the rough overall level of effort for this migration? A golf ball (relatively straightforward)

3. Is this going to be a rewrite of the code or a refactoring of the code? Refactoring (moving existing code into separately deployed services)

Now look at the dependency diagram shown in Figure 5-14. Unfortunately, this diagram is typical of the dependencies between components in most business applications. Notice in particular how the lefthand side of this diagram has the highest level of coupling, whereas the righthand side looks much more feasible to break apart.

Figure 5-14. A monolithic application with a high number of component dependencies takes more effort to break apart (basketball sizing)

With this level of tight coupling between components, the answers to the three key questions are not very encouraging:

1. Is it feasible to break apart the existing monolithic application? Maybe…

2. What is the rough overall level of effort for this migration? A basketball (much harder)

3. Is this going to be a rewrite of the code or a refactoring of the code? Likely a combination of some refactoring and some rewriting of the existing code

Finally, consider the dependency diagram illustrated in Figure 5-15. In this case, the architect should turn around and run in the opposite direction as fast as they can!

Figure 5-15. A monolithic application with too many component dependencies is not feasible to break apart (airliner sizing)

The answers to the three key questions for applications with this sort of component dependency matrix are not surprising:

1. Is it feasible to break apart the existing monolithic application? No

2. What is the rough overall level of effort for this migration? An airliner

3. Is this going to be a rewrite of the code or a refactoring of the code? Total rewrite of the application

We cannot stress enough the importance of these kinds of

Figure 5-16. Component dependencies in the Sysops Squad application

However, after further analysis, Addison saw that the Notification component had the most dependencies, which was not surprising given that it’s a shared component. However, Addison also saw lots of dependencies within the Ticketing and Reporting components. Both of these domain areas have a specific component for shared code (interfaces, helper classes, entity classes, and so on). Realizing that both the ticketing and reporting shared code contains mostly compile-based class references and would likely be implemented as shared libraries rather than services, Addison filtered out these components to get a better view of the dependencies between the core functionality of the application, which is illustrated in Figure 5-17.

Figure 5-17. Component dependencies in the Sysops Squad application without shared library dependencies

With the shared components filtered out, Addison saw that the dependencies were fairly minimal. Addison showed these results to Austen, and they both agreed that most of the components were relatively self-contained and it appeared that the Sysops Squad application was a good candidate for breaking apart into a distributed architecture.

When breaking apart monolithic applications, consider first moving to service-based architecture as a stepping-stone to other distributed architectures.

Creating component domains is an effective way of determining what will eventually become domain services in a service-based architecture.

Figure 5-18. Component domains are identified through the namespace nodes

Since many older monolithic applications were implemented prior to the widespread

Notice how each component is related to customer functionality, but the corresponding namespaces don’t reflect that association. To properly identify the Customer domain (manifested through the namespace ss.customer), the namespaces for the Billing Payment, Billing History, and Support Contract components would have to be modified to add the .customer node at the beginning of the namespace, as shown in Table 5-14.

Notice in the prior table that all of the customer-related functionality (billing, profile maintenance, and support contract maintenance) is now grouped under .customer, aligning each component with that particular domain.

Fitness Functions for Governance

Once refactored, it’s important to govern the component domains to ensure

public void restrict_domains() { classes() .should().resideInAPackage("..ss.ticket..") .orShould().resideInAPackage("..ss.customer..") .orShould().resideInAPackage("..ss.admin..") .check(myClasses); }

The exercise Addison did in diagramming and grouping the

Figure 5-19. The five domains identified (with darkened borders) within the Sysops Squad application

Addison started with the Ticket domain and saw that while the core ticket functionality started with the namespace ss.ticket, the survey and knowledge base components did not. Therefore, Addison wrote an architecture story to refactor the components listed in Table 5-15 to align with the ticketing domain.

Next Addison considered the customer-related components, and found that the billing and survey components needed to be refactored to include them under the Customer domain, creating a Billing subdomain in the process. Addison wrote an architecture story for the refactoring of the Customer domain functionality, shown in Table 5-16.

By applying the “Identify and Size Components Pattern”, Addison found that the reporting domain was already aligned, and no further action was needed with the reporting components listed in Table 5-17.

Addison saw that both the Admin and Shared domains needed alignment as well, and decided to create a single architecture story for this refactoring effort and listed these components in Table 5-18. Addison also decided to rename the ss.expert.profile namespace to ss.experts to avoid an unnecessary Expert subdomain under the Admin domain.

With this pattern complete, Addison realized they were now prepared to structurally break apart the monolithic application and move to the first stage of a distributed architecture by applying the Create Domain Services pattern (described in the next section).

In its simplest form, service-based architecture consists of a

Figure 5-20. The basic topology for a service-based architecture

In addition to the benefits mentioned in “Component-Based Decomposition”, moving to service-based architecture

Figure 5-21. Component domains are moved to external domain services

A word of advice, however: don’t apply this pattern until all of the component domains have been identified and refactored. This helps reduce the amount of modification needed to each domain service when moving components (and hence source code) around. For example, suppose all of the ticketing and knowledge base functionality in the Sysops Squad application was grouped and refactored into a Ticket domain, and a new Ticket service created from that domain. Now suppose that the customer survey component (identified through the ss.customer.survey namespace) was deemed part of the Ticket domain. Since the Ticket domain had already been migrated, the Ticket service would now have to be modified to include the Survey component. Better to align and refactor all of the components into component domains first, then start migrating those component domains to domain services.

Fitness Functions for Governance

It is important to keep the components within each domain service aligned with the domain,

public void restrict_domain_within_ticket_service() { classes().should().resideInAPackage("..ss.ticket..") .check(myClasses); }

Data Disintegrators

Data disintegration drivers provide answers and justifications

Change control

One of the primary data disintegration drivers is

controlling changes in the database table schemas. Dropping tables or columns, changing table or column names, and even changing the column type in a table break the corresponding SQL accessing those tables, and consequently break corresponding services using those tables. We call these types of changes breaking changes as opposed to adding tables or columns in a database, which generally do not impact existing queries or writes. Not surprisingly, change control is most impacted when using relational databases, but other database types can create change control issues as well (see

“Selecting a Database Type”).

As illustrated in Figure 6-2, when breaking changes occur to a database, multiple services must be updated, tested, and deployed together with the database changes. This coordination can quickly become both difficult and error prone as the number of separately deployed services sharing the same database increases. Imagine trying to coordinate 42 separately deployed services for a single breaking database change!

Figure 6-2. Services impacted by the database change must be deployed together with the database

Coordinating changes to multiple distributed services for a shared database change is only half the story.

The real danger of changing a shared database in any distributed architecture is forgetting about services that access the table just changed. As illustrated in

Figure 6-3, those services become nonoperational in production until they can be changed, tested, and redeployed.

Figure 6-3. Services impacted by a database change but forgotten will continue to fail until redeployed

In most applications, the danger of forgotten services is mitigated by diligent impact analysis and agressive regression testing. However, consider a microservices ecosystem with 400 services, all sharing the same monolithic highly available clustered relational database. Imagine running around to all the development teams in many domain areas, trying to find out which services use the table being changed. Also imagine having to then coordinate, test, and deploy all of these services together as a single unit, along with the database. Thinking about this scenario starts to become a mind-numbing exercise, usually leading to some degree of insanity.

Breaking apart a database into well-defined bounded contexts significantly

helps control breaking database changes. The bounded context concept comes from the seminal book Domain-Driven Design by Eric Evans (Addison-Wesley) and describes the source code, business logic, data structures, and data all bound together—encapsulated—within a specific context. As illustrated in

Figure 6-4, well-formed bounded contexts around services and their corresponding data helps control change, because change is isolated to just those services within that bounded context.

Most typically, bounded contexts are formed around services and the data

the services owns. By “own” we mean a service that writes to the database (as opposed to having read-only access to the data). We discuss distributed data ownership in more detail in

Chapter 9.

Figure 6-4. Database changes are isolated to only those services within the associated bounded context

Notice in Figure 6-4 that Service C needs access to some of the data in Database D that is contained in a bounded context with Service D. Since Database D is in a different bounded context, Service C cannot directly access the data. This would not only violate the bounded context rule, but also create a mess with regard to change control. Therefore, Service C must ask Service D for the data. There are many ways of accessing data a service doesn’t own while still maintaining a bounded context. These techniques are discussed in detail in Chapter 10.

One important aspect of a bounded context related to the scenario between Service C needing data and Service D

owning that data within its bounded context is that of database abstraction. Notice in

Figure 6-5 that Service D is sending data that was requested by Service C through some sort of contract (such as JSON, XML, or maybe even an object).

The advantage of the bounded context is that the data sent to Service C can be a different contract than the schema for Database D. This means that a breaking change to some table in Database D impacts only Service D and not necessarily the contract of the data sent to Service C. In other words, Service C is abstracted from the actual schema structure of Database D.

Figure 6-5. The contract from a service call abstracts the caller from the underlying database schema

To illustrate the power of this bounded context abstraction within a distributed architecture, assume Database D has a Wishlist table with the following structure:

CREATE TABLE Wishlist ( CUSTOMER_ID VARCHAR(10), ITEM_ID VARCHAR(20), QUANTITY INT, EXPIRATION_DT DATE );

The corresponding JSON contract that Service D sends to Service C requesting wish list items is as follows:

{ "$schema": "http://json-schema.org/draft-04/schema#", "properties": { "cust_id": {"type": "string"}, "item_id": {"type": "string"}, "qty": {"type": "number"}, "exp_dt": {"type": "number"} }, }

Notice how the expiration data field (exp_dt) in the JSON schema is named differently than the database column name and is specified as a number (a long value representing the epoch time—the number of milliseconds since midnight on 1 January 1970), whereas in the database it is represented as a DATE field. Any column name change or column type change made in the database no longer impacts Service C because of the separate JSON contract.

To illustrate this point, suppose the business decides to no longer expire wish list items. This would require a change in the table structure of the database:

ALTER TABLE Wishlist DROP COLUMN EXPIRATION_DT;

Service D would have to be modified to accommodate this change because it is within the same bounded context as the database, but the corresponding contract would not have to change at the same time. Until the contract is eventually changed, Service D could either specify a date far into the future or set the value to zero indicating the item doesn’t expire. The bottom line is that Service C is abstracted from breaking changes made to Database D due to the bounded context.

Connection management

Establishing a connection to a database is an expensive operation.

A database connection pool is often used not only to increase performance, but also to limit the number of concurrent connections an application is allowed to use.

In monolithic applications, the database connection pool is usually owned by the application (or application server). However, in distributed architectures, each service—or more specifically, each service instance—typically has its own connection pool.

As illustrated in

Figure 6-6, when multiple services share the same database, the number of connections can quickly become saturated, particularly as the number of services or service instances increase.

Figure 6-6. Database connections can quickly get saturated with multiple service instances

Reaching (or exceeding) the maximum number of available database connections is yet another driver to consider when deciding whether to break apart a database. Frequent connection waits (the amount of time it takes waiting for a connection to become available) is usually the first sign that the maximum number of database connections has been reached. Since connection waits can also manifest themselves as request time-outs or tripped circuit breakers, looking for connection waits is usually the first thing we recommend if these conditions frequently occur when using a shared database.

To illustrate the issues associated with database connections and distributed architecture, consider the following example: a monolithic application with 200 database connections is broken into a distributed architecture consisting of 50 services, each with 10 database connections in its connection pool.

Original monolithic application	200 connections
Distributed services	50
Connections per service	10
Minimum service instances	2
Total service connections	1,000

Notice how the number of database connections within the same application context grew from 200 to 1,000, and the services haven’t even started scaling yet! Assuming half of the services scale to an average of 5 instances each, the number of database connections quickly grows to 1,700.

Without some sort of connection strategy or governance plan, services

will try to use as many connections as possible, frequently starving other services from much needed connections. For this reason, it’s important to govern how database connections are used in a distributed architecture. One effective approach is to assign each service a connection quota to govern the distribution of available database connections across services. A connection quota specifies the maximum number of database connections a service is allowed to use or make available in its connection pool.

By specifying a connection quota, services are not allowed to create more database connections than are allocated to it. If a service reaches the maximum number of database connections in its quota, it must wait for one of the connections it’s using to become available. This method can be implemented using two approaches: evenly distributing the same connection quota to every service, or assigning a different connection quota to each service based on its needs.

The even distribution approach is typically used when first deploying services, and it is not known yet how many connections each service will need during normal and peak operations. While simple, this approach is not overly efficient because some services may need more connections than others, while some connections held by other services may go unused.

While more complex, the variable distribution approach is much more efficient for managing database connections to a shared database. With this approach, each service is assigned a different connection quota based on its functionality and scalability requirements. The advantage of this approach is that it optimizes the use of available database connections across distributed services, making sure those services that require more database connections have them available for use. However, the disadvantage is that it requires knowledge about the nature of the functionality and the scalability requirements of each service.

We usually recommend starting out with the even distribution approach and creating fitness functions to measure the concurrent connection usage for each service. We also recommend keeping the connection quota values in an external configuration server (or service) so that the values can be easily adjusted either manually or programmatically through simple machine learning algorithms. This technique not only helps mitigate connection saturation risk, but also properly balances available database connections between distributed services to ensure that no idle connections are wasted.

Table 6-1 shows an example of starting out using the even distribution approach for a database that can support a maximum of 100 concurrent connections. Notice that Service A has only ever needed a maximum of 5 connections, Service C only 15 connections, and Service E only 14 connections, whereas Service B and Service D have reached their max connection quota and have experienced connection waits.

Table 6-1. Connection quota allocations evenly distributed

	Service	Quota	Max used	Waits
	A	20	5	No
→	B	20	20	Yes
	C	20	15	No
→	D	20	20	Yes
	E	20	14	No

Since Service A is well below its connection quota, this is a good place to start reallocating connections to other services. Moving five database connections to Service B and five database connections to Service D yields the results shown in Table 6-2.

Table 6-2. Connection quota allocations with varying distributions

	Service	Quota	Max used	Waits
	A	10	5	No
→	B	25	25	Yes
	C	20	15	No
	D	25	25	No
	E	20	14	No

This is better, but Service B is still experiencing connection waits, indicating that it requires more connections than it has in its connection quota. Readjusting the quotas even further by taking two connections each from Service A and Service E yields much better results, as shown in Table 6-3.

Table 6-3. Further connection quota tuning results in no connection waits

Service	Quota	Max used	Waits
A	8	5	No
B	29	27	No
C	20	15	No
D	25	25	No
E	18	14	No

This analysis, which can be derived from continuous fitness functions that gather streamed metrics data from each service, can also be used to determine how close the maximum number of connections used is to the maximum number of connections available, and also how much buffer exists for each service in terms of its quota and maximum connections used.

Scalability

One of the many advantages of a distributed architecture

is scalability—the ability for services to handle increases in request volume while maintaining a consistent response time. Most cloud-based and on-prem infrastructure-related products do a good job at ensuring that services, containers, HTTP servers, and virtual machines scale to satisfy increases in demand. But what about the database?

As illustrated in

Figure 6-7,

service scalability can put a tremendous strain on the database, not only in terms of database connections (as discussed in the prior section), but also on throughput and database capacity. In order for a distributed system to scale, all parts of the system need to scale—including the database.

Figure 6-7. The database must also scale when services scale

Scalability is another data disintegration driver to consider when thinking about breaking apart a database. Database connections, capacity, throughput, and performance are all factors in determining whether a shared database can meet the demands of multiple services within a distributed architecture.

Consider the refined variable database connection quotas in

Table 6-3 in the prior section. When services scale by adding multiple instances, the picture changes dramatically, as shown in Table 6-4, where the total number of database connections is 100.

Table 6-4. When services scale, more connection are used than are available

Service	Quota	Max used	Instances	Total used
A	8	5	2	10
B	29	27	3	81
C	20	15	3	45
D	25	25	2	50
E	18	14	4	56
TOTAL	100	86	14	242

Notice that even though the connection quota is distributed to match the 100 database connections available, once services start to scale, the quota is no longer valid because the total number of connections used increases to 242, which is 142 more connections than are available in the database. This will likely result in connection waits, which in turn will result in overall performance degradation and request time-outs.

Breaking data into separate data domains or even

a database-per-service, as illustrated in

Figure 6-8, requires fewer connections to each database, hence providing better database scalability and performance as the services scale.

Figure 6-8. Breaking apart the database provides better database scalability

In addition to database connections, another factor to consider with respect to scalability is the load placed on the database. By breaking apart a database, less load is placed on each database, thereby also improving overall performance and scalability.

Fault tolerance

When multiple services share the same database, the overall

system becomes less fault tolerant because the database becomes a single point of failure (SPOF).

Here, we are defining fault tolerance as the ability of some parts of the system to continue uninterrupted when a service or database fails. Notice in

Figure 6-9 that when sharing a single database, overall fault tolerance is low because if the database goes down, all services become nonoperational.

Figure 6-9. If the database goes down, all services become nonoperational

Fault tolerance is another driver for considering breaking apart data. If fault tolerance is required for certain parts of the system, breaking apart the data can remove the single point of failure in the system, as shown in Figure 6-10. This ensures that some parts of the system are still operational in the event of a database crash.

Figure 6-10. Breaking apart the database achieves better fault tolerance

Notice that since the data is now broken apart, if Database B goes down, only Service B and Service C are impacted and become nonoperational, whereas the other services continue to operate uninterrupted.

Architectural quantum

Recall from Chapter 2 that an architectural quantum

is defined as an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling. The architecture quantum helps provide guidance in terms of when to break apart a database, making it another data disintegration driver.

Consider the services in

Figure 6-11, where Service A and Service B require different architectural characteristics than the other services. Notice in the diagram that although Service A and Service B are grouped together, they do not form a separate quantum from the other services because of a single shared database. Thus, all five services, along with the database, form a single architectural quantum.

Figure 6-11. The database is part of the architectural quantum

Because the database is included in the functional cohesion part of the architecture quantum definition,

it is necessary to break apart the data so that each resulting part can be in its own quantum. Notice in

Figure 6-12 that since the database is broken apart, Service A and Service B, along with the corresponding data, are now a separate quantum from the one formed with services C, D, and E.

Figure 6-12. Breaking up the database forms two architectural quanta

Data Integrators

Data integrators do the exact opposite of the data disintegrators discussed in the prior section.

Data relationships

Like components within an architecture, database tables can be coupled

as well, particularly with regard to relational databases. Artifacts like foreign keys, triggers, views, and stored procedures tie tables together, making it difficult to pull data apart; see Figure 6-13.

Imagine walking up to your DBA or data architect and telling them that since the database must be broken apart to support tightly formed bounded contexts within a microservices ecosystem, every foreign key and view in the database needs to be removed! That’s not a likely (or even feasible) scenario, yet that is precisely what would need to happen to support a database-per-service pattern in microservices.

Figure 6-13. Foreign keys (FK), triggers, and views create tightly coupled relationships between data

These artifacts are necessary in most relational databases to support data consistency and data integrity. In addition to these physical artifacts, data may also be logically related, such as a problem ticket table and its corresponding problem ticket status table. However, as illustrated in

Figure 6-14, these artifacts must be removed when moving data to another schema or database to form bounded contexts.

Figure 6-14. Data artifacts must be removed when breaking apart data

Notice that the foreign key (FK) relationship between the tables in Service A can be preserved because the data is in the same bounded context, schema, or database. However, the foreign keys (FK) between the tables in Service B and Service C must be removed (as well as the view that is used in Service C) because those tables are associated with different databases or schemas.

The relationship between data, either logical or physical, is a data integration driver, thus creating a trade-off between data disintegrators and data integrators. For example, is change control (a data disintegrator) more important than preserving the foreign key relationships between the tables (a data integrator)? Is fault tolerance (a data disintegrator) more important than preserving materialized views between tables (a data integrator)? Identifying what is more important helps make the decision about whether the data should be broken apart and what the resulting schema granularity should be.

Database transactions

Another data integrator is that of database transactions,

something we discuss in detail in

“Distributed Transactions”. As shown in Figure 6-15, when a single service does multiple database write actions to separate tables in the same database or schema, those updates can be done within an Atomicity, Consistency, Isolation, Durability (ACID) transaction and either committed or rolled back as a single unit of work.

Figure 6-15. A single transactional unit of work exists when the data is together

However, when data is broken apart into either separate schemas or databases, as illustrated in Figure 6-16, a single transactional unit of work no longer exists because of the remote calls between services. This means that an insert or update can be committed in one table, but not in the other tables because of error conditions, resulting in data consistency and integrity issues.

Figure 6-16. Single unit of work transactions don’t exist when data is broken apart

While we dive into the details of distributed transaction management and transactional sagas in Chapter 12, the point here is to emphasize that database transactions are yet another data integration driver, and should be taken into account when considering breaking apart a database.

Figure 6-20. Multiple services use the same database, accessing all the tables necessary for read or write purposes

The first step in breaking apart a database is to identify specific domain groupings within the database. For example, as shown in Table 6-5, related tables are grouped together to help identify possible data domains.

Step 2: Assign Tables to Data Domains

The next step is to group tables along a specific bounded context, assigning

Figure 6-21. Services use the primary schema according to their data domain needs

When tables belonging to different data domains are tightly coupled

ALTER SCHEMA payment TRANSFER sysops.billing;

SELECT history.ticket_id, history.notes, agent.name FROM ticket.ticket_history AS history INNER JOIN profile.sysops_user AS agent ON ( history.assigned_to_sysops_user_id = agent.sysops_user_id )