Building Evolutionary Architectures. 2nd Edition

Spis treści książki

• Foreword to the First Edition
• Foreword to the Second Edition
• Preface
  • The Structure of This Book
  • Case Studies and PenultimateWidgets
  • Conventions Used in This Book
  • Using Code Examples
  • OReilly Online Learning
  • How to Contact Us
  • Additional Information
  • Acknowledgments
• I. Mechanics
• 1. Evolving Software Architecture
  • The Challenges of Evolving Software
  • Evolutionary Architecture
    • Guided Change
    • Incremental Change
    • Multiple Architectural Dimensions
  • How Is Long-Term Planning Possible When Everything Changes All the Time?
  • Once Ive Built an Architecture, How Can I Prevent It from Degrading Over Time?
  • Why Evolutionary?
  • Summary
• 2. Fitness Functions
  • What Is a Fitness Function?
  • Categories
    • Scope: Atomic Versus Holistic
    • Cadence: Triggered Versus Continual Versus Temporal
    • Case Study: Triggered or Continuous?
    • Result: Static Versus Dynamic
    • Invocation: Automated Versus Manual
    • Proactivity: Intentional Versus Emergent
    • Coverage: Domain-Specific Fitness Functions?
  • Who Writes Fitness Functions?
  • Where Is My Fitness Function Testing Framework?
  • Outcomes Versus Implementations
  • Summary
• 3. Engineering Incremental Change
  • Incremental Change
    • Deployment Pipelines
    • Case Study: Adding Fitness Functions to PenultimateWidgets Invoicing Service
    • Case Study: Validating API Consistency in an Automated Build
  • Summary
• 4. Automating Architectural Governance
  • Fitness Functions as Architectural Governance
  • Code-Based Fitness Functions
    • Afferent and Efferent Coupling
    • Abstractness, Instability, and Distance from the Main Sequence
    • Directionality of Imports
    • Cyclomatic Complexity and Herding Governance
  • Turnkey Tools
    • Legality of Open Source Libraries
    • A11y and Other Supported Architecture Characteristics
    • ArchUnit
      • Package dependencies
      • Class dependency checks
      • Inheritance checks
      • Annotation checks
      • Layer checks
    • Linters for Code Governance
    • Case Study: Availability Fitness Function
    • Case Study: Load-Testing Along with Canary Releases
    • Case Study: What to Port?
    • Fitness Functions Youre Already Using
  • Integration Architecture
    • Communication Governance in Microservices
    • Case Study: Choosing How to Implement a Fitness Function
  • DevOps
  • Enterprise Architecture
    • Case Study: Architectural Restructuring While Deploying 60 Times per Day
    • Fidelity Fitness Functions
  • Fitness Functions as a Checklist, Not a Stick
  • Documenting Fitness Functions
  • Summary
• II. Structure
• 5. Evolutionary Architecture Topologies
  • Evolvable Architecture Structure
    • Connascence
      • Static connascence
      • Dynamic connascence
      • Connascence properties
    • Connascence Intersection with Bounded Context
  • Architectural Quanta and Granularity
    • Independently Deployable
    • High Functional Cohesion
    • High Static Coupling
    • Dynamic Quantum Coupling
      • Communication
      • Consistency
      • Coordination
  • Contracts
    • Case Study: Microservices as an Evolutionary Architecture
  • Reuse Patterns
    • Effective Reuse = Abstraction + Low Volatility
    • Sidecars and Service Mesh: Orthogonal Operational Coupling
    • Data Mesh: Orthogonal Data Coupling
      • Definition of Data Mesh
      • Data product quantum
  • Summary
• 6. Evolutionary Data
  • Evolutionary Database Design
    • Evolving Schemas
    • Shared Database Integration
      • Option 1: No integration points, no legacy data
      • Option 2: Legacy data, but no integration points
      • Option 3: Existing data and integration points
  • Inappropriate Data Entanglement
    • Two-Phase Commit Transactions
    • Age and Quality of Data
    • Case Study: Evolving PenultimateWidgets Routing
  • From Native to Fitness Function
    • Referential Integrity
    • Data Duplication
    • Replacing Triggers and Stored Procedures
    • Case Study: Evolving from Relational to Nonrelational
  • Summary
• III. Impact
• 7. Building Evolvable Architectures
  • Principles of Evolutionary Architecture
    • Last Responsible Moment
    • Architect and Develop for Evolvability
    • Postels Law
    • Architect for Testability
    • Conways Law
  • Mechanics
    • Step 1: Identify Dimensions Affected by Evolution
    • Step 2: Define Fitness Function(s) for Each Dimension
    • Step 3: Use Deployment Pipelines to Automate Fitness Functions
  • Greenfield Projects
  • Retrofitting Existing Architectures
    • Appropriate Coupling and Cohesion
    • COTS Implications
  • Migrating Architectures
    • Migration Steps
    • Evolving Module Interactions
  • Guidelines for Building Evolutionary Architectures
    • Remove Needless Variability
    • Make Decisions Reversible
    • Prefer Evolvable over Predictable
    • Build Anticorruption Layers
    • Build Sacrificial Architectures
    • Mitigate External Change
    • Updating Libraries Versus Frameworks
    • Version Services Internally
    • Case Study: Evolving PenultimateWidgets Ratings
  • Fitness Function-Driven Architecture
  • Summary
• 8. Evolutionary Architecture Pitfalls and Antipatterns
  • Technical Architecture
    • Antipattern: Last 10% Trap and Low Code/No Code
    • Case Study: Reuse at PenultimateWidgets
    • Antipattern: Vendor King
    • Pitfall: Leaky Abstractions
    • Pitfall: Resume-Driven Development
  • Incremental Change
    • Antipattern: Inappropriate Governance
    • Case Study: Just Enough Governance at PenultimateWidgets
    • Pitfall: Lack of Speed to Release
  • Business Concerns
    • Pitfall: Product Customization
    • Antipattern: Reporting Atop the System of Record
    • Pitfall: Excessively Long Planning Horizons
  • Summary
• 9. Putting Evolutionary Architecture into Practice
  • Organizational Factors
    • Dont Fight Conways Law
      • Default to cross-functional teams
      • Organize teams around business capabilities
      • Balance cognitive load with business capabilities
      • Think product over project
      • Avoid excessively large teams
      • Team coupling characteristics
    • Culture
    • Culture of Experimentation
    • CFO and Budgeting
  • The Business Case
    • Hypothesis- and Data-Driven Development
    • Fitness Functions as Experimental Media
      • Case study: UDP communications
      • Case study: Security dependencies
      • Case study: Concurrency fitness function
      • Case study: Fidelity fitness function
  • Building Enterprise Fitness Functions
    • Case Study: Zero-Day Security Vulnerability
    • Carving Out Bounded Contexts Within Existing Integration Architecture
  • Where Do You Start?
    • Low-Hanging Fruit
    • Highest Value First
    • Testing
    • Infrastructure
    • Case Study: Enterprise Architecture at PenultimateWidgets
  • Future State?
    • Fitness Functions Using AI
    • Generative Testing
  • Why (or Why Not)?
    • Why Should a Company Decide to Build an Evolutionary Architecture?
      • Predictable versus evolvable
      • Scale
      • Advanced business capabilities
      • Cycle time as a business metric
      • Isolating architectural characteristics at the quantum level
      • Adaptation versus evolution
    • Why Would a Company Choose Not to Build an Evolutionary Architecture?
      • Cant evolve a Big Ball of Mud
      • Other architectural characteristics dominate
      • Sacrificial architecture
      • Planning on closing the business soon
  • Summary
• Index

pokaż cały spis treści

ukryj recenzje