Architecture Patterns with Python.

Preface
	Managing Complexity, Solving Business Problems
	Why Python?
	TDD, DDD, and Event-Driven Architecture
	Who Should Read This Book
	A Brief Overview of What You’ll 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
	O’Reilly Online Learning
	How to Contact O’Reilly
	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
		Python’s 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, Let’s Avoid Making a Mess of Our Web Controllers
		And Let’s 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 Aren’t 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
	Aren’t 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 Couldn’t 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
	Postel’s Law and the Tolerant Reader Pattern
	Validating at the Edge
	Validating Semantics
	Validating Pragmatics
Index