book

Software Architecture: The Hard Parts

by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani

October 2021

Intermediate to advanced

462 pages

12h 32m

English

O'Reilly Media, Inc.

Audiobook available

Read now

Unlock full access

Conventions Used in This BookUsing Code ExamplesO’Reilly Online LearningHow to Contact UsAcknowledgmentsAcknowledgments from Mark RichardsAcknowledgments from Neal FordAcknowledgments from Pramod SadalageAcknowledgments from Zhamak Dehghani
Why “The Hard Parts”?Giving Timeless Advice About Software ArchitectureThe Importance of Data in ArchitectureArchitectural Decision RecordsArchitecture Fitness FunctionsUsing Fitness FunctionsArchitecture Versus Design: Keeping Definitions SimpleIntroducing the Sysops Squad SagaNonticketing WorkflowTicketing WorkflowA Bad ScenarioSysops Squad Architectural ComponentsSysops Squad Data Model
Architecture (Quantum | Quanta)Independently DeployableHigh Functional CohesionHigh Static CouplingDynamic Quantum CouplingSysops Squad Saga: Understanding Quanta
Modularity DriversMaintainabilityTestabilityDeployabilityScalabilityAvailability/Fault ToleranceSysops Squad Saga: Creating a Business Case
Is the Codebase Decomposable?Afferent and Efferent CouplingAbstractness and InstabilityDistance from the Main SequenceComponent-Based DecompositionTactical ForkingTrade-OffsSysops Squad Saga: Choosing a Decomposition Approach
Identify and Size Components PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Sizing ComponentsGather Common Domain Components PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Gathering Common ComponentsFlatten Components PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Flattening ComponentsDetermine Component Dependencies PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Identifying Component DependenciesCreate Component Domains PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Creating Component DomainsCreate Domain Services PatternPattern DescriptionFitness Functions for GovernanceSysops Squad Saga: Creating Domain ServicesSummary
Data Decomposition DriversData DisintegratorsData IntegratorsSysops Squad Saga: Justifying Database DecompositionDecomposing Monolithic DataStep 1: Analyze Database and Create Data DomainsStep 2: Assign Tables to Data DomainsStep 3: Separate Database Connections to Data DomainsStep 4: Move Schemas to Separate Database ServersStep 5: Switch Over to Independent Database ServersSelecting a Database TypeRelational DatabasesKey-Value DatabasesDocument DatabasesColumn Family DatabasesGraph DatabasesNewSQL DatabasesCloud Native DatabasesTime-Series DatabasesSysops Squad Saga: Polyglot Databases
Granularity DisintegratorsService Scope and FunctionCode VolatilityScalability and ThroughputFault ToleranceSecurityExtensibilityGranularity IntegratorsDatabase TransactionsWorkflow and ChoreographyShared CodeData RelationshipsFinding the Right BalanceSysops Squad Saga: Ticket Assignment GranularitySysops Squad Saga: Customer Registration Granularity

Code ReplicationWhen to UseShared LibraryDependency Management and Change ControlVersioning StrategiesWhen To UseShared ServiceChange RiskPerformanceScalabilityFault ToleranceWhen to UseSidecars and Service MeshWhen to UseSysops Squad Saga: Common Infrastructure LogicCode Reuse: When Does It Add Value?Reuse via PlatformsSysops Squad Saga: Shared Domain Functionality
Assigning Data OwnershipSingle Ownership ScenarioCommon Ownership ScenarioJoint Ownership ScenarioTable Split TechniqueData Domain TechniqueDelegate TechniqueService Consolidation TechniqueData Ownership SummaryDistributed TransactionsEventual Consistency PatternsBackground Synchronization PatternOrchestrated Request-Based PatternEvent-Based PatternSysops Squad Saga: Data Ownership for Ticket Processing
Interservice Communication PatternColumn Schema Replication PatternReplicated Caching PatternData Domain PatternSysops Squad Saga: Data Access for Ticket Assignment
Orchestration Communication StyleChoreography Communication StyleWorkflow State ManagementTrade-Offs Between Orchestration and ChoreographyState Owner and CouplingSysops Squad Saga: Managing Workflows
Transactional Saga PatternsEpic Saga(sao) PatternPhone Tag Saga(sac) PatternFairy Tale Saga(seo) PatternTime Travel Saga(sec) PatternFantasy Fiction Saga(aao) PatternHorror Story(aac) PatternParallel Saga(aeo) PatternAnthology Saga(aec) PatternState Management and Eventual ConsistencySaga State MachinesTechniques for Managing SagasSysops Squad Saga: Atomic Transactions and Compensating Updates
Strict Versus Loose ContractsTrade-Offs Between Strict and Loose ContractsContracts in MicroservicesStamp CouplingOver-Coupling via Stamp CouplingBandwidthStamp Coupling for Workflow ManagementSysops Squad Saga: Managing Ticketing Contracts
Previous ApproachesThe Data WarehouseThe Data LakeThe Data MeshDefinition of Data MeshData Product QuantumData Mesh, Coupling, and Architecture QuantumWhen to Use Data MeshSysops Squad Saga: Data Mesh
Finding Entangled DimensionsCouplingAnalyze Coupling PointsAssess Trade-OffsTrade-Off TechniquesQualitative Versus Quantative AnalysisMECE ListsThe “Out-of-Context” TrapModel Relevant Domain CasesPrefer Bottom Line over Overwhelming EvidenceAvoiding Snake Oil and EvangelismSysops Squad Saga: Epilogue

Content preview from Software Architecture: The Hard Parts

Appendix A. Concept and Term References

In this book, we’ve made several references to terms or concepts that are explained in detail in our previous book, Fundamentals of Software Architecture. The following is a forward reference for those terms and concepts:

Cyclomatic complexity: Chapter 6, page 81

Component coupling: Chapter 7, page 92

Component cohesion: Chapter 7, page 93

Technical versus domain partitioning: Chapter 8, page 103

Layered architecture: Chapter 10, page 135

Service-based architecture: Chapter 13, page 163

Microservices architecture: Chapter 12, page 151