Get ebook downloads in full at ebookmeta.

com

Software Architecture Patterns Understanding

Common Architectural Styles and When to Use Them
2nd Edition Mark Richards

https://ebookmeta.com/product/software-architecture-
patterns-understanding-common-architectural-styles-and-when-
to-use-them-2nd-edition-mark-richards/

OR CLICK BUTTON

DOWNLOAD NOW

Explore and download more ebook at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Software Architecture Patterns Understanding Common

Architecture Patterns And When To Use Them 3rd Edition
Mark Richards
https://ebookmeta.com/product/software-architecture-patterns-
understanding-common-architecture-patterns-and-when-to-use-them-3rd-
edition-mark-richards/
ebookmeta.com

Head First Software Architecture A Learner's Guide to

Architectural Thinking (3rd Early Release) 3rd Edition
Raju Gandhi
https://ebookmeta.com/product/head-first-software-architecture-a-
learners-guide-to-architectural-thinking-3rd-early-release-3rd-
edition-raju-gandhi/
ebookmeta.com

Design Elements Third Edition Understanding the rules and

knowing when to break them A Visual Communication Manual
Timothy Samara
https://ebookmeta.com/product/design-elements-third-edition-
understanding-the-rules-and-knowing-when-to-break-them-a-visual-
communication-manual-timothy-samara/
ebookmeta.com

Chaos Is a Gift Leading Oneself in Uncertain and Complex

Environments 1st Edition Ebben Van Zyl Andrew Campbell
Liezel Lues
https://ebookmeta.com/product/chaos-is-a-gift-leading-oneself-in-
uncertain-and-complex-environments-1st-edition-ebben-van-zyl-andrew-
campbell-liezel-lues/
ebookmeta.com
Flame Carmichael Family 5 1st Edition Adriana Locke

https://ebookmeta.com/product/flame-carmichael-family-5-1st-edition-
adriana-locke/

ebookmeta.com

Whole Lotta Grump (Grumps Unleashed Book 3) 1st Edition

Cassie Mint

https://ebookmeta.com/product/whole-lotta-grump-grumps-unleashed-
book-3-1st-edition-cassie-mint/

ebookmeta.com

Island Love: ALOHA LOVE. 1st Edition Imani Jay.

https://ebookmeta.com/product/island-love-aloha-love-1st-edition-
imani-jay/

ebookmeta.com

Ash (Daddies of the Shadows Book 2) 1st Edition Kate

Oliver

https://ebookmeta.com/product/ash-daddies-of-the-shadows-book-2-1st-
edition-kate-oliver-2/

ebookmeta.com

A Psychology of User Experience: Involvement, Affect and

Aesthetics 2nd Edition Phil Turner

https://ebookmeta.com/product/a-psychology-of-user-experience-
involvement-affect-and-aesthetics-2nd-edition-phil-turner/

ebookmeta.com
Death by Identity Theft Second Edition Ken Buckler

https://ebookmeta.com/product/death-by-identity-theft-second-edition-
ken-buckler/

ebookmeta.com
 SECOND EDITION

Software Architecture
Patterns
Understanding Common Architectural
Styles and When to Use Them

Mark Richards

Beijing Boston Farnham Sebastopol Tokyo

Software Architecture Patterns
by Mark Richards
Copyright © 2022 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional
use. Online editions are also available for most titles (http://oreilly.com). For more
information, contact our corporate/institutional sales department: 800-998-9938 or
[email protected].

Acquisitions Editor: Melissa Duffield Interior Designer: David Futato

Development Editor: Shira Evans Cover Designer: Randy Comer
Production Editor: Kristen Brown Illustrator: Rob Romano
Copyeditor: Sonia Saruba

February 2015: First Edition

July 2022: Second Edition

Revision History for the Second Edition

2022-07-29: First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Software Architec‐
ture Patterns, the cover image, and related trade dress are trademarks of O’Reilly
Media, Inc.
While the publisher and the author have used good faith efforts to ensure that
the information and instructions contained in this work are accurate, the publisher
and the author disclaim all responsibility for errors or omissions, including without
limitation responsibility for damages resulting from the use of or reliance on this
work. Use of the information and instructions contained in this work is at your
own risk. If any code samples or other technology this work contains or describes is
subject to open source licenses or the intellectual property rights of others, it is your
responsibility to ensure that your use thereof complies with such licenses and/or
rights.

978-1-098-13427-3
[LSI]
 Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Architectural Structures and Styles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Architecture Classification 5
Architecture Partitioning 9

3. Layered Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Description 15
Key Concepts 17
Examples 20
Considerations and Analysis 21

4. Microkernel Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Topology 25
Examples 27
Considerations and Analysis 29

5. Event-Driven Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Topology 33
Example Architecture 35
Event-Driven Versus Message-Driven 37
Considerations and Analysis 38

6. Microservices Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Basic Topology 43
What Is a Microservice? 45
Bounded Context 45

iii
 Unique Features 47
Examples and Use Cases 48
Considerations and Analysis 49

7. Space-Based Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Topology and Components 56
Examples 60
Considerations and Analysis 61

A. Style Analysis Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iv | Table of Contents
 CHAPTER 1
Introduction

It’s all too common for developers to start coding an application

without a formal architecture in place. This practice usually results
in ill-defined components, creating what is commonly referred to
as a big ball of mud. These architectures are generally tightly cou‐
pled, brittle, difficult to change, and lack a clear vision or direction.
It’s also very difficult to determine the architectural characteristics
of applications lacking a well-defined architectural style. Does the
architecture scale? What are the performance characteristics of the
application? How easy is it to change the application or add new
features? How responsive is the architecture?
Architecture styles help define the basic characteristics and behavior
of an application. Some architecture styles naturally lend themselves
toward highly scalable systems, whereas other architecture styles
naturally lend themselves toward applications that allow develop‐
ers to respond quickly to change. Knowing the characteristics,
strengths, and weaknesses of each architecture style is necessary to
choose the one that meets your specific business needs and goals.
A lot has happened in software architecture since 2015 when the
first edition of this report was published. Both microservices and
event-driven architecture have gained in popularity, and develop‐
ers and architects have found new techniques, tools, and ways
of designing and implementing these architecture styles. Also, the
widespread use of domain-driven design has led to a better under‐
standing of how architectures are structurally partitioned, and how
that partitioning can impact the design and implementation of a

1
system. The second edition of the report addresses both of these
advances.
The second edition also includes other significant enhancements,
along with more information about the intersection of architecture
and data, and an expanded analysis section at the end of each chap‐
ter. These new sections provide you with better guidelines for when
to use (and not to use) each architecture presented in this report.
Another change you’ll notice in the second edition is the use of
the term architecture style rather than architecture pattern for the
architectures described in this report. This distinction helps alleviate
some of the confusion surrounding the differences between, say,
event-driven architecture—an architecture style—and something
like CQRS (Command Query Responsibility Segregation), which is
an architecture pattern.
An architecture style, such as the ones presented in this report,
describe the macro structure of a system. Architecture patterns, on
the other hand, describe reusable structural building block patterns
that can be used within each of the architecture styles to solve a par‐
ticular problem. Take, for example, the well known CQRS pattern,
which describes the structural separation between read and write
operations to a database or eventing system (for example, separate
services and databases for read operations and write operations).
This architecture pattern could be applied to any of the architecture
styles described in this report to optimize database queries and
updates.
Architecture patterns, in turn, differ from design patterns (such as
the Builder design pattern) in that an architecture pattern impacts
the structural aspect of a system, whereas a design pattern impacts
how the source code is designed. For example, you can use the
Builder design pattern as a way to implement the CQRS architecture
pattern, and then use the CQRS pattern as a building block within
a microservices architecture. Figure 1-1 shows this hierarchical rela‐
tionship among the three terms and how they interrelate with each
other to build software systems.

2 | Chapter 1: Introduction
Figure 1-1. Architecture styles can be composed of architecture pat‐
terns, which in turn can be composed of design patterns

Design patterns and architecture patterns are typically combined to

form a complete solution. Architecture styles act in the same way—
they can also be combined when building software solutions to form
a complete solution. Hybrid architecture styles are common in the
real world because not every architecture style can solve every busi‐
ness problem. Common architecture style hybrids include event-
driven microservices (events between microservices), space-based
microservices (processing units implemented as microservices), and
even an event-driven microkernel architecture (events between the
core system and remote plug-in components). Although forming
hybrids is a common practice, it is vital to understand individ‐
ual architecture styles and their corresponding strengths and weak‐
nesses before combining them.
The goal of this updated second edition report remains the same as
the first edition: to help senior developers and architects understand
some of the more common architecture styles, how they work, when
to use them, and when not to use them. This will help to not only
expand your knowledge of architecture, but will also help you make
the right architecture choice for your systems.

Introduction | 3
 CHAPTER 2
Architectural Structures and Styles

Architecture styles allow you to use existing and well-known struc‐

tures that support certain architectural characteristics (also known
as nonfunctional quality attributes, system quality attributes, or
“-ilities”). They not only provide you with a head start on defining
an architecture for a given system, but they also facilitate communi‐
cation among developers, architects, quality assurance testers, oper‐
ations experts, and even in some cases, business stakeholders.

Architecture Classification
Architecture styles are classified as belonging to one of two main
architectural structures: monolithic (single deployment unit) and
distributed (multiple deployment units, usually consisting of serv‐
ices). This classification is important to understand because as a
group, distributed architectures support much different architecture
characteristics than monolithic ones. Knowing which classification
of architecture to use is the first step in selecting the right architec‐
ture for your business problem.

Monolithic Architectures
Monolithic architecture styles (as illustrated in Figure 2-1) are gen‐
erally much simpler than distributed ones, and as such are easier to
design and implement. These single deployment unit applications
are fairly inexpensive from an overall cost standpoint. Furthermore,
most applications architected using a monolithic architecture style

5
can be developed and deployed much more quickly than distributed
ones.

Figure 2-1. Monolithic architectures are single deployment units

While cost and simplicity are the main strong points of a monolithic
architecture, operational characteristics such as scalability, fault tol‐
erance, and elasticity are its weak points. A fatal error (such as an
out of memory condition) in a monolithic architecture causes all
of the functionality to fail. Furthermore, mean time to recovery
(MTTR) and mean time to start (MTTS) are usually measured in
minutes, meaning that once a failure does occur, it takes a long time
for the application to start back up. These long startup times also
impact scalability and elasticity. While scalability can sometimes be
achieved through load balancing multiple instances of the applica‐
tion, the entire application functionality must scale, even if only a
small portion of the overall application needs to scale. This is not
only inefficient, but unnecessarily costly as well.
Examples of monolithic architecture styles include the layered
architecture (described in Chapter 3), the modular monolith, the
pipeline architecture, and the microkernel architecture (described in
Chapter 4).

6 | Chapter 2: Architectural Structures and Styles

Distributed Architectures
As the name suggests, distributed architectures consist of multiple
deployment units that work together to perform some sort of cohe‐
sive business function. In today’s world, most distributed architec‐
tures consist of services, although each distributed architecture style
has its own unique formal name for a service. Figure 2-2 illustrates a
typical distributed architecture.

Figure 2-2. Distributed architectures consist of multiple deployment

units

The superpowers of distributed architectures usually fall within

operational characteristics—things like scalability, elasticity, fault
tolerance, and in some cases, performance. Scalability in these
architecture styles is typically at the individual service level, as is
elasticity. Hence, MTTS and MTTR are much smaller than with a
monolithic application, measured usually in seconds (and in some
cases milliseconds) rather than minutes.
Distributed architectures are well suited for supporting high levels
of fault tolerance. If one service fails, in many cases other services
can continue to service requests as if no fault happened. Services
that do fail can recover very quickly—so quickly that at times an end
user sometimes doesn’t even know the service had a fatal error.

Architecture Classification | 7
Agility (the ability to respond quickly to change) is often another
superpower of distributed architectures. Because application func‐
tionality is divided into separately deployed units of software, it is
easier to locate and apply a change, the testing scope is reduced
to only the service that is impacted, and deployment risk is sig‐
nificantly reduced because only the service impacted is typically
deployed.
Unfortunately, with all those good features come some bad features
as well. Distributed architectures are plagued with what are known
as the fallacies of distributed computing, a set of eight things we
believe to be true about networks and distributed computing, but
are in fact false. Things like “the network is reliable,” “bandwidth is
infinite,” and “latency is zero” all make distributed architectures not
only hard to keep deterministic, but also hard to make completely
reliable. Networks do fail, bandwidth is not infinite, and latency is
not zero. These things are as real today as they were back in the
late ’90s when they were coined.
In addition to the eight fallacies of distributed computing, other
difficulties arise with distributed architectures. Distributed transac‐
tions, eventual consistency, workflow management, error handling,
data synchronization, contract management, and a host of other
complexities are all part of the world of distributed architecture. To
top it off, all this complexity usually means much more cost from an
overall initial implementation and ongoing maintenance cost than
monolithic architectures. Suddenly, all of those great superpowers
don’t sound so great anymore when you consider all the trade-offs of
distributed architectures.
Examples of distributed architectures include event-driven archi‐
tecture (described in Chapter 5), the ever-popular microservices
architecture (described in Chapter 6), service-based architec‐
ture, service-oriented architecture, and space-based architecture
(described in Chapter 7).

Which One Should I Choose?

When choosing between a monolithic versus a distributed architec‐
ture, one question to first ask yourself is if the system you are
creating has different sets of architecture characteristics that must
be supported. In other words, does the entire system need to scale
and support high availability, or only parts of the system? Systems

8 | Chapter 2: Architectural Structures and Styles

that contain multiple sets of different architecture characteristics
generally call for a distributed architecture. A good example of this
is customer-facing functionality requiring support for scalability,
responsiveness, availability, and agility, and an administrative or
backend processing functionality that doesn’t need any of those
characteristics.
Simple systems or websites usually warrant the simpler and more
cost-effective monolithic architecture style, whereas more complex
systems that perform multiple business functions usually warrant
more complex distributed architectures. Similarly, the “need for
speed,” the need for high volumes of scalability, and the need
for high fault tolerance are all characteristics that lend themselves
toward distributed architectures.

Architecture Partitioning
Besides being classified as either monolithic or distributed, architec‐
tures can also be classified by the way the overall structure of the
system is partitioned. Architectures, whether they are monolithic
or distributed, can be either technically partitioned or domain par‐
titioned. The following sections describe the differences between
these partitioning structures and why it’s important to understand
them.

Technical Partitioning
Technically partitioned architectures have the components of the
system organized by technical usage. The classic example of a techni‐
cally partitioned architecture is the layered (n-tiered) architecture
style (see Chapter 3). In this architecture style, components are
organized by technical layers; for example, presentation components
that have to do with the user interface, business layer components
that have to do with business rules and core processing, persistence
layer components that interact with the database, and the database
layer containing the data for the system.
Notice in Figure 2-3 that the components of any given domain are
spread across all of these technical layers. For example, the customer
domain functionality resides in the presentation layer as customer
screens, the business layer as customer logic, the presentation layer
as customer queries, and the database layer as customer tables.
Manifested as namespaces, these components would be organized

Architecture Partitioning | 9
as follows: app.presentation.customer, app.business.customer,
app.persistence.customer, and so on. Notice how the second
node in the namespace specifies the technical layering, and that the
customer node is spread across those layers.

Figure 2-3. In a technically partitioned architecture, components are

grouped by their technical usage

Technically partitioned architectures are useful if a majority of your

changes are isolated to a specific technical area in the application.
For example, if you are constantly changing the look and feel of
your user interface without changing the corresponding business
rules, change is isolated to only one part of the architecture (in
this case, the presentation layer). Similarly, if your business rules
are constantly changing but there is no impact to the data layer or
presentation layer, changes are isolated to the business layer of the
architecture with no impact to other parts of the system.
However, imagine implementing a new requirement to add an
expiration data to items for customer wish lists in a technically
partitioned architecture. This type of change is considered a
domain-based change (not a technical usage one), and impacts all of
the layers of the architecture. To implement this change, you would
need to add a new column to the wish list table in the database layer,
change the corresponding SQL in the persistence layer, add the
corresponding business rules to components in the business layer,
change the contracts between the business and presentation layer,

10 | Chapter 2: Architectural Structures and Styles

Other documents randomly have
different content
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status by
the Internal Revenue Service. The Foundation’s EIN or federal
tax identification number is 64-6221541. Contributions to the
Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or
determine the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About Project

Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
back
back
back