Architecture Patterns with Python. Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices

Kup polskie wydanie:

Spis treści ebooka

• Preface
  • Managing Complexity, Solving Business Problems
  • Why Python?
  • TDD, DDD, and Event-Driven Architecture
  • Who Should Read This Book
  • A Brief Overview of What Youll Learn
    • Part I, Building an Architecture to Support Domain Modeling
    • Part II, Event-Driven Architecture
    • Addtional Content
  • Example Code and Coding Along
  • License
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact OReilly
  • Acknowledgments
• Introduction
  • Why Do Our Designs Go Wrong?
  • Encapsulation and Abstractions
  • Layering
  • The Dependency Inversion Principle
  • A Place for All Our Business Logic: The Domain Model
• I. Building an Architecture to Support Domain Modeling
• 1. Domain Modeling
  • What Is a Domain Model?
  • Exploring the Domain Language
  • Unit Testing Domain Models
    • Dataclasses Are Great for Value Objects
    • Value Objects and Entities
  • Not Everything Has to Be an Object: A Domain Service Function
    • Pythons Magic Methods Let Us Use Our Models with Idiomatic Python
    • Exceptions Can Express Domain Concepts Too
• 2. Repository Pattern
  • Persisting Our Domain Model
  • Some Pseudocode: What Are We Going to Need?
  • Applying the DIP to Data Access
  • Reminder: Our Model
    • The Normal ORM Way: Model Depends on ORM
    • Inverting the Dependency: ORM Depends on Model
  • Introducing the Repository Pattern
    • The Repository in the Abstract
    • What Is the Trade-Off?
  • Building a Fake Repository for Tests Is Now Trivial!
  • What Is a Port and What Is an Adapter, in Python?
  • Wrap-Up
• 3. A Brief Interlude: On Coupling and Abstractions
  • Abstracting State Aids Testability
  • Choosing the Right Abstraction(s)
  • Implementing Our Chosen Abstractions
    • Testing Edge to Edge with Fakes and Dependency Injection
    • Why Not Just Patch It Out?
  • Wrap-Up
• 4. Our First Use Case: Flask API and Service Layer
  • Connecting Our Application to the Real World
  • A First End-to-End Test
  • The Straightforward Implementation
  • Error Conditions That Require Database Checks
  • Introducing a Service Layer, and Using FakeRepository to Unit Test It
    • A Typical Service Function
  • Why Is Everything Called a Service?
  • Putting Things in Folders to See Where It All Belongs
  • Wrap-Up
    • The DIP in Action
• 5. TDD in High Gear and Low Gear
  • How Is Our Test Pyramid Looking?
  • Should Domain Layer Tests Move to the Service Layer?
  • On Deciding What Kind of Tests to Write
  • High and Low Gear
  • Fully Decoupling the Service-Layer Tests from the Domain
    • Mitigation: Keep All Domain Dependencies in Fixture Functions
    • Adding a Missing Service
  • Carrying the Improvement Through to the E2E Tests
  • Wrap-Up
• 6. Unit of Work Pattern
  • The Unit of Work Collaborates with the Repository
  • Test-Driving a UoW with Integration Tests
  • Unit of Work and Its Context Manager
    • The Real Unit of Work Uses SQLAlchemy Sessions
    • Fake Unit of Work for Testing
  • Using the UoW in the Service Layer
  • Explicit Tests for Commit/Rollback Behavior
  • Explicit Versus Implicit Commits
  • Examples: Using UoW to Group Multiple Operations into an Atomic Unit
    • Example 1: Reallocate
    • Example 2: Change Batch Quantity
  • Tidying Up the Integration Tests
  • Wrap-Up
• 7. Aggregates and Consistency Boundaries
  • Why Not Just Run Everything in a Spreadsheet?
  • Invariants, Constraints, and Consistency
    • Invariants, Concurrency, and Locks
  • What Is an Aggregate?
  • Choosing an Aggregate
  • One Aggregate = One Repository
  • What About Performance?
  • Optimistic Concurrency with Version Numbers
    • Implementation Options for Version Numbers
  • Testing for Our Data Integrity Rules
    • Enforcing Concurrency Rules by Using Database Transaction Isolation Levels
    • Pessimistic Concurrency Control Example: SELECT FOR UPDATE
  • Wrap-Up
  • Part I Recap
• II. Event-Driven Architecture
• 8. Events and the Message Bus
  • Avoiding Making a Mess
    • First, Lets Avoid Making a Mess of Our Web Controllers
    • And Lets Not Make a Mess of Our Model Either
    • Or the Service Layer!
  • Single Responsibility Principle
  • All Aboard the Message Bus!
    • The Model Records Events
    • Events Are Simple Dataclasses
    • The Model Raises Events
    • The Message Bus Maps Events to Handlers
  • Option 1: The Service Layer Takes Events from the Model and Puts Them on the Message Bus
  • Option 2: The Service Layer Raises Its Own Events
  • Option 3: The UoW Publishes Events to the Message Bus
  • Wrap-Up
• 9. Going to Town on the Message Bus
  • A New Requirement Leads Us to a New Architecture
    • Imagining an Architecture Change: Everything Will Be an Event Handler
  • Refactoring Service Functions to Message Handlers
    • The Message Bus Now Collects Events from the UoW
    • Our Tests Are All Written in Terms of Events Too
    • A Temporary Ugly Hack: The Message Bus Has to Return Results
    • Modifying Our API to Work with Events
  • Implementing Our New Requirement
    • Our New Event
  • Test-Driving a New Handler
    • Implementation
    • A New Method on the Domain Model
  • Optionally: Unit Testing Event Handlers in Isolation with a Fake Message Bus
  • Wrap-Up
    • What Have We Achieved?
    • Why Have We Achieved?
• 10. Commands and Command Handler
  • Commands and Events
  • Differences in Exception Handling
  • Discussion: Events, Commands, and Error Handling
  • Recovering from Errors Synchronously
  • Wrap-Up
• 11. Event-Driven Architecture: Using Events to Integrate Microservices
  • Distributed Ball of Mud, and Thinking in Nouns
  • Error Handling in Distributed Systems
  • The Alternative: Temporal Decoupling Using Asynchronous Messaging
  • Using a Redis Pub/Sub Channel for Integration
  • Test-Driving It All Using an End-to-End Test
    • Redis Is Another Thin Adapter Around Our Message Bus
    • Our New Outgoing Event
  • Internal Versus External Events
  • Wrap-Up
• 12. Command-Query Responsibility Segregation (CQRS)
  • Domain Models Are for Writing
  • Most Users Arent Going to Buy Your Furniture
  • Post/Redirect/Get and CQS
  • Hold On to Your Lunch, Folks
  • Testing CQRS Views
  • Obvious Alternative 1: Using the Existing Repository
  • Your Domain Model Is Not Optimized for Read Operations
  • Obvious Alternative 2: Using the ORM
  • SELECT N+1 and Other Performance Considerations
  • Time to Completely Jump the Shark
    • Updating a Read Model Table Using an Event Handler
  • Changing Our Read Model Implementation Is Easy
  • Wrap-Up
• 13. Dependency Injection (and Bootstrapping)
  • Implicit Versus Explicit Dependencies
  • Arent Explicit Dependencies Totally Weird and Java-y?
  • Preparing Handlers: Manual DI with Closures and Partials
  • An Alternative Using Classes
  • A Bootstrap Script
  • Message Bus Is Given Handlers at Runtime
  • Using Bootstrap in Our Entrypoints
  • Initializing DI in Our Tests
  • Building an Adapter Properly: A Worked Example
    • Define the Abstract and Concrete Implementations
    • Make a Fake Version for Your Tests
    • Figure Out How to Integration Test the Real Thing
  • Wrap-Up
• Epilogue
  • What Now?
  • How Do I Get There from Here?
  • Separating Entangled Responsibilities
  • Identifying Aggregates and Bounded Contexts
  • An Event-Driven Approach to Go to Microservices via Strangler Pattern
  • Convincing Your Stakeholders to Try Something New
  • Questions Our Tech Reviewers Asked That We Couldnt Work into Prose
  • Footguns
  • More Required Reading
  • Wrap-Up
• A. Summary Diagram and Table
• B. A Template Project Structure
  • Env Vars, 12-Factor, and Config, Inside and Outside Containers
  • Config.py
  • Docker-Compose and Containers Config
  • Installing Your Source as a Package
  • Dockerfile
  • Tests
  • Wrap-Up
• C. Swapping Out the Infrastructure: Do Everything with CSVs
  • Implementing a Repository and Unit of Work for CSVs
• D. Repository and Unit of Work Patterns with Django
  • Repository Pattern with Django
    • Custom Methods on Django ORM Classes to Translate to/from Our Domain Model
  • Unit of Work Pattern with Django
  • API: Django Views Are Adapters
  • Why Was This All So Hard?
  • What to Do If You Already Have Django
  • Steps Along the Way
• E. Validation
  • What Is Validation, Anyway?
  • Validating Syntax
  • Postels Law and the Tolerant Reader Pattern
  • Validating at the Edge
  • Validating Semantics
  • Validating Pragmatics
• Index

pokaż cały spis treści

ukryj recenzje