Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith Sam Newman

Kup polskie wydanie:

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• Preface
  • What You Will Learn
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• 1. Just Enough Microservices
  • What Are Microservices?
    • Independent Deployability
    • Modeled Around a Business Domain
    • Own Their Own Data
    • What Advantages Can Microservices Bring?
    • What Problems Do They Create?
    • User Interfaces
    • Technology
    • Size
    • And Ownership
  • The Monolith
    • The Single Process Monolith
      • And the modular monolith
    • The Distributed Monolith
    • Third-Party Black-Box Systems
    • Challenges of Monoliths
    • Advantages of Monoliths
  • On Coupling and Cohesion
    • Cohesion
    • Coupling
      • Implementation coupling
      • Temporal coupling
      • Deployment coupling
      • Domain coupling
  • Just Enough Domain-Driven Design
    • Aggregate
    • Bounded Context
    • Mapping Aggregates and Bounded Contexts to Microservices
    • Further Reading
  • Summary
• 2. Planning a Migration
  • Understanding the Goal
    • Three Key Questions
  • Why Might You Choose Microservices?
    • Improve Team Autonomy
      • How else could you do this?
    • Reduce Time to Market
      • How else could you do this?
    • Scale Cost-Effectively for Load
      • How else could you do this?
    • Improve Robustness
      • How else could you do this?
    • Scale the Number of Developers
      • How else could you do this?
    • Embrace New Technology
      • How else could you do this?
  • When Might Microservices Be a Bad Idea?
    • Unclear Domain
    • Startups
    • Customer-Installed and Managed Software
    • Not Having a Good Reason!
  • Trade-Offs
  • Taking People on the Journey
  • Changing Organizations
    • Establishing a Sense of Urgency
    • Creating the Guiding Coalition
    • Developing a Vision and Strategy
    • Communicating the Change Vision
    • Empowering Employees for Broad-Based Action
    • Generating Short-Term Wins
    • Consolidating Gains and Producing More Change
    • Anchoring New Approaches in the Culture
  • Importance of Incremental Migration
    • Its Production That Counts
  • Cost of Change
    • Reversible and Irreversible Decisions
    • Easier Places to Experiment
  • So Where Do We Start?
  • Domain-Driven Design
    • How Far Do You Have to Go?
    • Event Storming
    • Using a Domain Model for Prioritization
  • A Combined Model
  • Reorganizing Teams
    • Shifting Structures
    • Its Not One Size Fits All
    • Making a Change
    • Changing Skills
  • How Will You Know if the Transition Is Working?
    • Having Regular Checkpoints
    • Quantitative Measures
    • Qualitative Measures
    • Avoiding the Sunk Cost Fallacy
    • Being Open to New Approaches
  • Summary
• 3. Splitting the Monolith
  • To Change the Monolith, or Not?
    • Cut, Copy, or Reimplement?
    • Refactoring the Monolith
      • A modular monolith?
      • Incremental rewrites
  • Migration Patterns
  • Pattern: Strangler Fig Application
    • How It Works
    • Where to Use It
    • Example: HTTP Reverse Proxy
      • Step 1: Insert proxy
      • Step 2: Migrate functionality
      • Step 3: Redirect calls
    • Data?
    • Proxy Options
      • Incremental rollout
    • Changing Protocols
      • And service meshes
    • Example: FTP
    • Example: Message Interception
      • Content-based routing
      • Selective consumption
    • Other Protocols
    • Other Examples of the Strangler Fig Pattern
  • Changing Behavior While Migrating Functionality
  • Pattern: UI Composition
    • Example: Page Composition
    • Example: Widget Composition
      • And mobile applications
    • Example: Micro Frontends
    • Where to Use It
  • Pattern: Branch by Abstraction
    • How It Works
      • Step 1: Create abstraction
      • Step 2: Use abstraction
      • Step 3: Create new implementation
      • Step 4: Switch implementation
      • Step 5: Clean up
    • As a Fallback Mechanism
    • Where to Use It
  • Pattern: Parallel Run
    • Example: Comparing Credit Derivative Pricing
    • Example: Homegate Listings
    • Verification Techniques
    • Using Spies
    • GitHub Scientist
    • Dark Launching and Canary Releasing
    • Where to Use It
  • Pattern: Decorating Collaborator
    • Example: Loyalty Program
    • Where to Use It
  • Pattern: Change Data Capture
    • Example: Issuing Loyalty Cards
    • Implementing Change Data Capture
      • Database triggers
      • Transaction log pollers
      • Batch delta copier
    • Where to Use It
  • Summary
• 4. Decomposing the Database
  • Pattern: The Shared Database
    • Coping Patterns
    • Where to Use It
  • But It Cant Be Done!
  • Pattern: Database View
    • The Database as a Public Contract
    • Views to Present
    • Limitations
    • Ownership
    • Where to Use It
  • Pattern: Database Wrapping Service
    • Where to Use It
  • Pattern: Database-as-a-Service Interface
    • Implementing a Mapping Engine
    • Compared to Views
    • Where to Use It
  • Transferring Ownership
    • Pattern: Aggregate Exposing Monolith
      • As a pathway to more services
      • Where to use it
      • Where to use it
    • Pattern: Change Data Ownership
      • Where to use it
  • Data Synchronization
  • Pattern: Synchronize Data in Application
    • Step 1: Bulk Synchronize Data
    • Step 2: Synchronize on Write, Read from Old Schema
    • Step 3: Synchronize on Write, Read from New Schema
    • Where to Use This Pattern
    • Where to Use It
  • Pattern: Tracer Write
    • Data Synchronization
    • Example: Orders at Square
      • Creating the new service
      • Synchronizing the data
      • Migrating consumers
    • Where to Use It
  • Splitting Apart the Database
    • Physical Versus Logical Database Separation
  • Splitting the Database First, or the Code?
    • Split the Database First
      • Pattern: Repository per bounded context
        • Where to use it
      • Pattern: Database per bounded context
        • Where to use it
    • Split the Code First
      • Pattern: Monolith as data access layer
        • Where to use it
      • Pattern: Multischema storage
        • Where to use it
    • Split Database and Code Together
    • So, Which Should I Split First?
  • Schema Separation Examples
  • Pattern: Split Table
    • Where to Use It
  • Pattern: Move Foreign-Key Relationship to Code
    • Moving the Join
    • Data Consistency
      • Check before deletion
      • Handle deletion gracefully
      • Dont allow deletion
      • So how should we handle deletion?
    • Where to Use It
    • Example: Shared Static Data
      • Pattern: duplicate static reference data
        • Where to use it
      • Pattern: Dedicated reference data schema
        • Where to use it
      • Pattern: Static reference data library
        • Where to use it
      • Pattern: Static reference data service
        • Where to use it
      • What would I do?
  • Transactions
    • ACID Transactions
    • Still ACID, but Lacking Atomicity?
    • Two-Phase Commits
    • Distributed TransactionsJust Say No
  • Sagas
    • Saga Failure Modes
      • Saga rollbacks
      • Reordering steps to reduce rollbacks
      • Mixing fail-backward and fail-forward situations
    • Implementing Sagas
      • Orchestrated sagas
      • Choreographed sagas
      • Mixing styles
      • Should I use choreography or orchestration?
    • Sagas Versus Distributed Transactions
  • Summary
• 5. Growing Pains
  • More Services, More Pain
  • Ownership at Scale
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
  • Breaking Changes
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
      • Eliminate accidental breaking changes
      • Think twice before making a breaking change
      • Give consumers time to migrate
  • Reporting
    • When Might This Problem Occur?
    • Potential Solutions
  • Monitoring and Troubleshooting
    • When Might These Problems Occur?
    • How Can These Problems Occur?
    • Potential Solutions
      • Log aggregation
      • Tracing
      • Test in production
      • Toward observability
  • Local Developer Experience
    • How Can This Problem Show Itself?
    • When Might This Occur?
    • Potential Solutions
  • Running Too Many Things
    • How Might This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
  • End-to-End Testing
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
      • Limit scope of functional automated tests
      • Use consumer-driven contracts
      • Use automated release remediation and progressive delivery
      • Continually refine your quality feedback cycles
  • Global Versus Local Optimization
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
  • Robustness and Resiliency
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
  • Orphaned Services
    • How Can This Problem Show Itself?
    • When Might This Problem Occur?
    • Potential Solutions
  • Summary
• 6. Closing Words
• A. Bibliography
• B. Pattern Index
• Index

pokaż cały spis treści

ukryj recenzje