Fundamentals of Software Architecture, 2nd Edition A Modern Engineering Approach (Mark Richards, Neal Ford) (z-library.sk, 1lib.sk, z-lib.sk)

Page 1

Mark Richards & Neal Ford Fundamentals of Software Architecture A Modern Engineering Approach 2nd Edition

Page 2

9 7 8 1 0 9 8 1 7 5 5 1 1 5 7 9 9 9 ISBN: 978-1-098-17551-1 US $79.99 CAN $99.99 SOF T WARE ARCHITEC TURE Developers who want to move beyond coding to advance their career aspire to become software architects, yet no real guide has existed to help them do so—until now. This updated edition provides a comprehensive overview of software architecture’s many aspects, with several entirely new chapters covering the latest insights from the field. Existing and prospective architects alike will examine architectural characteristics, architectural patterns, component determination, diagramming architecture, governance, data, generative AI, team topologies, and many other topics. Mark Richards and Neal Ford—hands-on practitioners who have taught software architecture classes professionally for years—focus on architecture principles that apply across all technology stacks. You’ll explore software architecture in a modern light, taking into account all the innovations of the past decade. This book examines: • Architecture styles and patterns: Microservices, modular monoliths, microkernels, layered architectures, and many more • Components: Identification, coupling, cohesion, partitioning, and granularity • Soft skills: Effective team management, collaboration, business engagement models, negotiation, presentations, and more • Modern engineering practices: Methods and operational approaches that have changed radically in the past few years, including cloud considerations and generative AI • Architecture as an engineering discipline: Repeatable results, metrics, and concrete valuations that add rigor to software architecture Mark Richards is an experienced hands-on software architect involved in the architecture, design, and implementation of microservices architectures and other distributed systems. He’s the author of numerous O’Reilly technical books and videos. Neal Ford is a director, software architect, and meme wrangler at Thoughtworks and an internationally recognized expert on software development and delivery. Neal’s authored eight books (and counting), a number of magazine articles, and dozens of video presentations. Fundamentals of Software Architecture “An indispensable resource for exploring modern software architecture through a contemporary lens. Whether you are an ‘accidental’ architect stepping into the role or a veteran seeking to ref ine 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

Page 3

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

Page 4

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

Page 5

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

Page 6

978-1-098-17551-1 [LSI] 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.

Page 7

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Defining Software Architecture 2 Laws of Software Architecture 6 Expectations of an Architect 8 Make Architecture Decisions 8 Continually Analyze the Architecture 9 Keep Current with Latest Trends 9 Ensure Compliance with Decisions 10 Understand Diverse Technologies 10 Know the Business Domain 11 Possess Interpersonal Skills 11 Understand and Navigate Politics 12 Roadmap 13 Part I. Foundations 2. Architectural Thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Architecture Versus Design 17 Strategic Versus Tactical Decisions 18 Level of Effort 19 The Significance of Trade-Offs 19 Technical Breadth 20 v

Page 8

The 20-Minute Rule 24 Developing a Personal Radar 25 Analyzing Trade-Offs 30 Understanding Business Drivers 33 Balancing Architecture and Hands-On Coding 33 There’s More to Architectural Thinking 36 3. Modularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Modularity Versus Granularity 38 Defining Modularity 38 Measuring Modularity 40 Cohesion 41 Coupling 44 Core Metrics 45 Distance from the Main Sequence 46 Connascence 49 From Modules to Components 54 4. Architectural Characteristics Defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Architectural Characteristics and System Design 56 Architectural Characteristics (Partially) Listed 59 Operational Architectural Characteristics 59 Structural Architectural Characteristics 60 Cloud Characteristics 60 Cross-Cutting Architectural Characteristics 61 Trade-Offs and Least Worst Architecture 64 5. Identifying Architectural Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Extracting Architectural Characteristics from Domain Concerns 67 Composite Architectural Characteristics 68 Extracting Architectural Characteristics 69 Working with Katas 70 Kata: Silicon Sandwiches 71 Explicit Characteristics 72 Implicit Characteristics 75 Limiting and Prioritizing Architectural Characteristics 77 6. Measuring and Governing Architecture Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . 81 Measuring Architecture Characteristics 81 vi | Table of Contents

Page 9

Operational Measures 82 Structural Measures 83 Process Measures 86 Governance and Fitness Functions 86 Governing Architecture Characteristics 86 Fitness Functions 87 7. The Scope of Architectural Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Architectural Quanta and Granularity 96 Synchronous Communication 99 The Impact of Scoping 100 Scoping and Architectural Style 102 Kata: Going Green 103 Scoping and the Cloud 105 8. Component-Based Thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Defining Logical Components 107 Logical Versus Physical Architecture 110 Creating a Logical Architecture 112 Identifying Core Components 113 Assigning User Stories to Components 117 Analyzing Roles and Responsibilities 118 Analyzing Architectural Characteristics 120 Restructuring Components 120 Component Coupling 121 Static Coupling 121 Temporal Coupling 122 The Law of Demeter 123 Case Study: Going, Going, Gone—Discovering Components 125 Part II. Architecture Styles 9. Foundations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Styles Versus Patterns 131 Fundamental Patterns 133 Big Ball of Mud 133 Unitary Architecture 134 Client/Server 135 Table of Contents | vii

Page 10

Architecture Partitioning 137 Kata: Silicon Sandwiches—Partitioning 140 Monolithic Versus Distributed Architectures 143 Fallacy #1: The Network Is Reliable 144 Fallacy #2: Latency Is Zero 144 Fallacy #3: Bandwidth Is Infinite 145 Fallacy #4: The Network Is Secure 146 Fallacy #5: The Topology Never Changes 147 Fallacy #6: There Is Only One Administrator 148 Fallacy #7: Transport Cost Is Zero 148 Fallacy #8: The Network Is Homogeneous 149 The Other Fallacies 149 Team Topologies and Architecture 151 On to Specific Styles 152 10. Layered Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Topology 153 Style Specifics 155 Layers of Isolation 155 Adding Layers 157 Data Topologies 159 Cloud Considerations 159 Common Risks 159 Governance 159 Team Topology Considerations 160 Style Characteristics 161 When to Use 162 When Not to Use 163 Examples and Use Cases 163 11. The Modular Monolith Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Topology 165 Style Specifics 166 Monolithic Structure 167 Modular Structure 168 Module Communication 168 Data Topologies 170 Cloud Considerations 171 Common Risks 171 viii | Table of Contents

Page 11

Governance 172 Team Topology Considerations 174 Style Characteristics 175 When to Use 176 When Not to Use 177 Examples and Use Cases 177 12. Pipeline Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Topology 181 Style Specifics 182 Filters 182 Pipes 183 Data Topologies 184 Cloud Considerations 184 Common Risks 185 Governance 186 Team Topology Considerations 188 Style Characteristics 189 When to Use 190 When Not to Use 190 Examples and Use Cases 191 13. Microkernel Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Topology 193 Style Specifics 194 Core System 194 Plug-In Components 198 The Spectrum of “Microkern-ality” 200 Registry 201 Contracts 201 Data Topologies 202 Cloud Considerations 203 Common Risks 203 Volatile Core 203 Plug-In Dependencies 204 Governance 204 Team Topology Considerations 204 Architecture Characteristics Ratings 205 Examples and Use Cases 207 Table of Contents | ix

Page 12

14. Service-Based Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Topology 209 Style Specifics 211 Service Design and Granularity 213 User Interface Options 213 API Gateway Options 215 Data Topologies 215 Cloud Considerations 219 Common Risks 219 Governance 219 Team Topology Considerations 220 Style Characteristics 221 Examples and Use Cases 224 15. Event-Driven Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Topology 228 Style Specifics 232 Events Versus Messages 232 Derived Events 233 Triggering Extensible Events 235 Asynchronous Capabilities 235 Broadcast Capabilities 239 Event Payload 240 The Swarm of Gnats Antipattern 246 Error Handling 249 Preventing Data Loss 253 Request-Reply Processing 256 Mediated Event-Driven Architecture 258 Data Topologies 268 Monolithic Database Topology 269 Domain Database Topology 271 Dedicated Data Topology 273 Cloud Considerations 275 Common Risks 275 Governance 276 Team Topology Considerations 276 Style Characteristics 277 Choosing Between Request-Based and Event-Based Models 280 Examples and Use Cases 280 x | Table of Contents

Page 13

16. Space-Based Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Topology 284 Style Specifics 286 Processing Unit 286 Virtualized Middleware 287 Messaging Grid 287 Data Grid 288 Processing Grid 296 Deployment Manager 297 Data Pumps 297 Data Writers 298 Data Readers 300 Data Topologies 302 Cloud Considerations 302 Common Risks 303 Frequent Reads from the Database 303 Data Synchronization and Consistency 304 High Data Volumes 304 Data Collisions 304 Governance 307 Team Topology Considerations 310 Style Characteristics 311 Examples and Use Cases 313 Concert Ticketing System 313 Online Auction System 313 17. Orchestration-Driven Service-Oriented Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Topology 315 Style Specifics 316 Taxonomy 317 Reuse…and Coupling 320 Data Topologies 322 Cloud Considerations 323 Common Risks 323 Governance 324 Team Topology Considerations 325 Style Characteristics 325 Examples and Use Cases 327 Table of Contents | xi

Page 14

18. Microservices Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Topology 330 Style Specifics 331 Bounded Context 331 Granularity 332 Data Isolation 333 API Layer 334 Operational Reuse 334 Frontends 338 Communication 339 Choreography and Orchestration 341 Transactions and Sagas 345 Data Topologies 348 Cloud Considerations 351 Common Risks 351 Governance 352 Team Topology Considerations 353 Style Characteristics 354 Examples and Use Cases 356 19. Choosing the Appropriate Architecture Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Shifting “Fashion” in Architecture 359 Decision Criteria 361 Monolith Case Study: Silicon Sandwiches 364 Modular Monolith 365 Microkernel 366 Distributed Case Study: Going, Going, Gone 367 20. Architectural Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Reuse 372 Separating Domain and Operational Coupling 372 Communication 375 Orchestration Versus Choreography 375 CQRS 378 Infrastructure 379 Broker-Domain Pattern 380 xii | Table of Contents

Page 15

Part III. Techniques and Soft Skills 21. Architectural Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Architectural Decision Antipatterns 387 The Covering Your Assets Antipattern 387 Groundhog Day Antipattern 389 Email-Driven Architecture Antipattern 389 Architectural Significance 390 Architectural Decision Records 391 Basic Structure 392 Example 398 Storing ADRs 400 ADRs as Documentation 401 Using ADRs for Standards 402 Using ADRs with Existing Systems 402 Leveraging Generative AI and LLMs in Architectural Decisions 402 22. Analyzing Architecture Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Risk Matrix 405 Risk Assessments 406 Risk Storming 410 Phase 1: Identification 411 Phase 2: Consensus 412 Phase 3: Risk Mitigation 415 User-Story Risk Analysis 416 Risk-Storming Use Case 416 Availability 418 Elasticity 420 Security 421 Summary 422 23. Diagramming Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Diagramming 424 Tools 424 Diagramming Standards: UML, C4, and ArchiMate 426 Diagram Guidelines 428 Summary 431 Table of Contents | xiii

Page 16

24. Making Teams Effective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Collaboration 433 Constraints and Boundaries 435 Architect Personalities 436 The Control-Freak Architect 437 The Armchair Architect 437 The Effective Architect 438 How Much Involvement? 439 Team Warning Signs 443 Process Loss 443 Pluralistic Ignorance 444 Leveraging Checklists 445 Developer Code-Completion Checklist 447 Unit and Functional Testing Checklist 448 Software-Release Checklist 449 Providing Guidance 450 Summary 452 25. Negotiation and Leadership Skills. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Negotiation and Facilitation 453 Negotiating with Business Stakeholders 453 Negotiating with Other Architects 456 Negotiating with Developers 457 The Software Architect as a Leader 459 The 4 Cs of Architecture 459 Be Pragmatic, Yet Visionary 461 Leading Teams by Example 462 Integrating with the Development Team 465 Summary 468 26. Architectural Intersections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Architecture and Implementation 470 Operational Concerns 471 Structural Integrity 472 Architectural Constraints 474 Architecture and Infrastructure 475 Architecture and Data Topologies 477 Database Topology 478 Architectural Characteristics 479 xiv | Table of Contents

Page 17

Data Structure 479 Read/Write Priority 479 Architecture and Engineering Practices 480 Architecture and Team Topologies 481 Architecture and Systems Integration 482 Architecture and the Enterprise 482 Architecture and the Business Environment 483 Architecture and Generative AI 484 Incorporating Generative AI into Architecture 484 Generative AI as an Architect Assistant 484 Summary 485 27. The Laws of Software Architecture, Revisited. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 First Law: Everything in Software Architecture Is a Trade-Off 487 Shared Library Versus Shared Service 488 Synchronous Versus Asynchronous Messaging 490 First Corollary: Missing Trade-Offs 492 Second Corollary: You Can’t Do It Just Once 494 Second Law: Why Is More Important Than How 494 Out of Context Antipattern 494 The Spectrum Between Extremes 495 Parting Words of Advice 496 Appendix. Discussion Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Table of Contents | xv

Page 18

(This page has no text content)

Page 19

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 Chap‐ ter 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 indisputa‐ bly 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. xvii

Page 20

The software development ecosystem exists in a constant state of dynamic equili‐ brium: 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 pro‐ cesses—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 capa‐ bilities. 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 xviii | Preface