Fundamentals of Software Architecture (Mark Richards, Neal Ford) (Z-Library)

Praise for Fundamentals of Software Architecture Mark and Neal have done it again—this revised and expanded second edition of their bestseller is an indispensable resource for exploring modern software architecture through a contemporary lens. With a nuanced understanding of what software architecture truly involves, this comprehensive guide starts with the critical importance of trade- off analysis, then delves into a wide range of architectural styles and the philosophies that underpin them, along with detailed examinations of data and team topologies. Whether you are an “accidental” architect stepping into the role or a seasoned veteran seeking to refine your skills, this book offers the tools and knowledge you need to excel in your craft. —Raju Gandhi, Author of Head First Git and Coauthor of Head First Software Architecture

Neal and Mark aren’t just outstanding software architects; they are also exceptional teachers. With Fundamentals of Software Architecture, they have managed to condense the sprawling topic of architecture into a concise work that reflects their decades of experience. Whether you’re new to the role or you’ve been a practicing architect for many years, the updated edition of this book will help you be better at your job. I only wish they’d have written it earlier in my career. I’ve now used both editions with my architecture graduate students, and will continue to recommend it widely in this expanded form. —Nathaniel Schutta, Coauthor of Fundamentals of Software Engineering Mark and Neal set out to achieve a formidable goal—to elucidate the many, layered fundamentals required to excel in software architecture —and they have once again completed their quest. The software architecture field continuously evolves, and the role requires a daunting breadth and depth of knowledge and skills. This updated book will serve as a guide for many as they navigate their journey to software architecture mastery. —Rebecca J. Parsons, Technology Advisor and Former CTO/CTO Emerita, Thoughtworks

Mark and Neal truly capture real-world advice for technologists to drive architecture excellence. They achieve this by identifying common architecture characteristics and the trade-offs that are necessary to drive success. —Cassie Shum, Technical Director, Thoughtworks OceanofPDF.com

Fundamentals of Software Architecture SECOND EDITION A Modern Engineering Approach Mark Richards and Neal Ford OceanofPDF.com

Fundamentals of Software Architecture by Mark Richards and Neal Ford Copyright © 2025 Mark Richards and Neal Ford. 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 corporate@oreilly.com. Acquisitions Editor: Louise Corrigan Development Editor: Sarah Grey Production Editor: Christopher Faucher Copyeditor: Sonia Saruba Proofreader: Piper Content Partners Indexer: WordCo Indexing Services, Inc.

Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea January 2020: First Edition March 2025: Second Edition Revision History for the Second Edition 2025-03-12: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098175511 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Fundamentals of Software Architecture, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors 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-17551-1 [LSI] OceanofPDF.com

Preface Preface to the Second Edition “Wow, there’s a lot there!” When we set out to write the second edition of Fundamentals of Software Architecture, we had a few ideas of things we wanted to flesh out and improve from the first edition, but like a lot of software projects, it kept growing. One of our met goals was to make the styles sections more consistent, making them more useful for comparisons. We also made some changes to our star ratings to add sections and a few new categories, and added new sections on cloud considerations, data topologies, team topologies, and governance for each architectural style. Along the way we made major additions to a number of chapters on popular topics, such as Chapters 15 and 18, and added a new chapter (Chapter 11) on the modular monolith architectural style. We also added several entirely new chapters covering architectural patterns in Chapter 20, the intersections of architecture in Chapter 26, and revisiting our laws of software architecture (of which there is a new corollary and a new law) in Chapter 27.

Preface to the First Edition Axiom A statement or proposition that is regarded as being established, accepted, or self-evidently true. Mathematicians create theories based on axioms—assumptions for things indisputably true. Software architects also build theories atop axioms, but the software world is, well, softer than mathematics: fundamental things continue to change at a rapid pace, including the axioms we base our theories upon. The software development ecosystem exists in a constant state of dynamic equilibrium: while it exists in a balanced state at any given point in time, it exhibits dynamic behavior over the long term. A great modern example of the nature of this ecosystem follows the ascension of containerization and the attendant changes: tools like Kubernetes didn’t exist a decade ago, yet now entire software conferences exist to service its users. The software ecosystem changes chaotically: one small change causes another small change; when repeated hundreds of times, it generates a new ecosystem. Architects have an important responsibility to question assumptions and axioms left over from previous eras. Many of the books about software architecture were written in an era that only barely resembles the current world. In fact, the authors believe that we must question fundamental

axioms on a regular basis, in light of improved engineering practices, operational ecosystems, software development processes— everything that makes up the messy, dynamic equilibrium where architects and developers work each day. Careful observers of software architecture over time witnessed an evolution of capabilities. Starting with the engineering practices of Extreme Programming, continuing with continuous delivery, the DevOps revolution, microservices, containerization, and now cloud-based resources, all of these innovations led to new capabilities and trade-offs. As capabilities changed, so did architects’ perspectives on the industry. For many years, the tongue- in-cheek definition of software architecture was “the stuff that’s hard to change later.” Later, the microservices architecture style appeared, where change is a first-class design consideration. Each new era requires new practices, tools, measurements, patterns, and a host of other changes. This book looks at software architecture in a modern light, taking into account all the innovations from the last decade, along with some new metrics and measures suited to today’s new structures and perspectives. The subtitle of our book is “A Modern Engineering Approach.” Developers have long wished to change software development from a craft, where skilled artisans can create one-off works, to an engineering discipline, which implies repeatability, rigor, and effective analysis. While software

engineering still lags behind other types of engineering disciplines by many orders of magnitude (to be fair, software is a very young discipline compared to most other types of engineering), architects have made huge improvements, which we’ll discuss. In particular, modern Agile engineering practices have allowed great strides in the types of systems that architects design. We also address the critically important issue of trade-off analysis. As a software developer, it’s easy to become enamored with a particular technology or approach. But architects must always soberly assess the good, bad, and ugly of every choice, and virtually nothing in the real world offers convenient binary choices— everything is a trade-off. Given this pragmatic perspective, we strive to eliminate value judgments about technology and instead focus on analyzing trade-offs to equip our readers with an analytic eye toward technology choices. This book won’t make someone a software architect overnight— it’s a nuanced field with many facets. We want to provide existing and burgeoning architects a good modern overview of software architecture and its many aspects, from structure to soft skills. While this book covers well- known patterns, we take a new approach, leaning on lessons learned, tools, engineering practices, and other input. We take many existing axioms in software architecture and rethink them in light of the current ecosystem, and design architectures, taking the modern landscape into account.

Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords. TIP This element signifies a tip or suggestion. NOTE This element signifies a general note. WARNING This element indicates a warning or caution.

Supplemental Material Visit http://fundamentalsofsoftwarearchitecture.com to access the supplemental resources for this book. If you have a technical question or a problem using the code examples, please send email to bookquestions@oreilly.com. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Fundamentals of Software Architecture, Second Edition, by Mark Richards and Neal Ford (O’Reilly). Copyright 2025 Mark Richards and Neal Ford, 978-1-098-17551-1.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. O’Reilly Online Learning NOTE For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North

Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/fundamentals-of-software-architecture-2e. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media. Watch us on YouTube: https://youtube.com/oreillymedia. Acknowledgments Mark and Neal would like to thank all the people who attended our classes, workshops, conference sessions, and user group meetings, as well as all the people who listened to versions of this material and provided invaluable

feedback. We would also like to thank the publishing team at O’Reilly, who made this as painless an experience as writing a book can be. In particular, we would like to thank our first edition editors, Alicia Young and Virginia Wilson, and our second edition editor, Sarah Grey. Acknowledgments from Mark Richards In addition to the preceding acknowledgments, I would like to thank my lovely wife, Rebecca. Taking everything else on at home and sacrificing the opportunity to work on your own book allowed me to do additional consulting gigs and speak at more conferences and training classes, giving me the opportunity to practice and hone the material for this book. You are the best. 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 we can improve them. Thoughtworks supported this book in many ways and continues to grow Thoughtworkers who challenge and inspire every day. I would also like to thank our neighborhood cocktail club for a regular escape from routine. Lastly, I would like to thank my wife, Candy, whose tolerance for things like book writing and conference speaking apparently

knows no bounds. For decades she’s kept me grounded and sane enough to function, and I hope she will for decades more as the love of my life. OceanofPDF.com

Chapter 1. Introduction So you’re interested in software architecture. Perhaps you’re a developer who wants to move to the next career step, or perhaps you are a project manager who wants to understand what happens when software architectures work. You may also be an “accidental architect”: someone who makes architecture decisions (defined below) but doesn’t have the title of “software architect"…yet. Why delve into the realm of software architecture? Perhaps you have experience with lots of projects and want to understand more deeply how the larger parts of systems fit together, along with the numerous trade-offs. If so, software architecture is an obvious next career step. This book is designed for all of you. It provides an overview of the extremely multifaceted job of “software architect.” Software architects must understand and analyze software systems deeply, in all their complexity, and must make important trade-off decisions, sometimes with incomplete information. Many software developers worried that generative AI might slowly replace them are considering moving to software architecture, a role much harder to replace. Software architects make exactly the kinds of decisions that AI cannot, evaluating trade-offs within complex, changing contexts.

Architecture, like much art, can only be understood in context. Architects base their decisions on the realities of their environment. For example, one of the major goals of late-20th-century software architecture was to use shared infrastructure and resources as efficiently as possible, because operating systems, application servers, database servers, and so on were all commercial and very expensive. In 2002, trying to build an architecture like microservices would have been inconceivably expensive. Imagine strolling into a 2002 data center and telling the head of operations, “Hey, I have a great idea for a revolutionary style of architecture, where each service runs on its own isolated machinery with its own dedicated database. I’ll need 50 Windows licenses, another 30 application-server licenses, and at least 50 database server licenses.” We can only build such architectures today because of the advent of open source and the updated engineering practices of the DevOps revolution. All architectures are products of their context—keep that in mind as you read this book. Defining Software Architecture So what is software architecture? Figure 1-1 illustrates how we like to think about software architecture. This definition has four dimensions. The software architecture of a system consists of an architecture style as the starting point, combined with the architecture characteristics it must