book

Architecture Patterns with Python

by Harry Percival, Bob Gregory

March 2020

Intermediate to advanced

301 pages

7h 10m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Managing Complexity, Solving Business ProblemsWhy Python?TDD, DDD, and Event-Driven ArchitectureWho Should Read This BookA Brief Overview of What You’ll LearnPart I, Building an Architecture to Support Domain ModelingPart II, Event-Driven ArchitectureAddtional ContentExample Code and Coding AlongLicenseConventions Used in This BookO’Reilly Online LearningHow to Contact O’ReillyAcknowledgments
Why Do Our Designs Go Wrong?Encapsulation and AbstractionsLayeringThe Dependency Inversion PrincipleA Place for All Our Business Logic: The Domain Model
What Is a Domain Model?Exploring the Domain LanguageUnit Testing Domain ModelsDataclasses Are Great for Value ObjectsValue Objects and EntitiesNot Everything Has to Be an Object: A Domain Service FunctionPython’s Magic Methods Let Us Use Our Models with Idiomatic PythonExceptions Can Express Domain Concepts Too
Persisting Our Domain ModelSome Pseudocode: What Are We Going to Need?Applying the DIP to Data AccessReminder: Our ModelThe “Normal” ORM Way: Model Depends on ORMInverting the Dependency: ORM Depends on ModelIntroducing the Repository PatternThe Repository in the AbstractWhat 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
Abstracting State Aids TestabilityChoosing the Right Abstraction(s)Implementing Our Chosen AbstractionsTesting Edge to Edge with Fakes and Dependency InjectionWhy Not Just Patch It Out?Wrap-Up
Connecting Our Application to the Real WorldA First End-to-End TestThe Straightforward ImplementationError Conditions That Require Database ChecksIntroducing a Service Layer, and Using FakeRepository to Unit Test ItA Typical Service FunctionWhy Is Everything Called a Service?Putting Things in Folders to See Where It All BelongsWrap-UpThe DIP in Action
How Is Our Test Pyramid Looking?Should Domain Layer Tests Move to the Service Layer?On Deciding What Kind of Tests to WriteHigh and Low GearFully Decoupling the Service-Layer Tests from the DomainMitigation: Keep All Domain Dependencies in Fixture FunctionsAdding a Missing ServiceCarrying the Improvement Through to the E2E TestsWrap-Up
The Unit of Work Collaborates with the RepositoryTest-Driving a UoW with Integration TestsUnit of Work and Its Context ManagerThe Real Unit of Work Uses SQLAlchemy SessionsFake Unit of Work for TestingUsing the UoW in the Service LayerExplicit Tests for Commit/Rollback BehaviorExplicit Versus Implicit CommitsExamples: Using UoW to Group Multiple Operations into an Atomic UnitExample 1: ReallocateExample 2: Change Batch QuantityTidying Up the Integration TestsWrap-Up
Why Not Just Run Everything in a Spreadsheet?Invariants, Constraints, and ConsistencyInvariants, Concurrency, and LocksWhat Is an Aggregate?Choosing an AggregateOne Aggregate = One RepositoryWhat About Performance?Optimistic Concurrency with Version NumbersImplementation Options for Version NumbersTesting for Our Data Integrity RulesEnforcing Concurrency Rules by Using Database Transaction Isolation LevelsPessimistic Concurrency Control Example: SELECT FOR UPDATEWrap-UpPart I Recap

Avoiding Making a MessFirst, Let’s Avoid Making a Mess of Our Web ControllersAnd Let’s Not Make a Mess of Our Model EitherOr the Service Layer!Single Responsibility PrincipleAll Aboard the Message Bus!The Model Records EventsEvents Are Simple DataclassesThe Model Raises EventsThe Message Bus Maps Events to HandlersOption 1: The Service Layer Takes Events from the Model and Puts Them on the Message BusOption 2: The Service Layer Raises Its Own EventsOption 3: The UoW Publishes Events to the Message BusWrap-Up
A New Requirement Leads Us to a New ArchitectureImagining an Architecture Change: Everything Will Be an Event HandlerRefactoring Service Functions to Message HandlersThe Message Bus Now Collects Events from the UoWOur Tests Are All Written in Terms of Events TooA Temporary Ugly Hack: The Message Bus Has to Return ResultsModifying Our API to Work with EventsImplementing Our New RequirementOur New EventTest-Driving a New HandlerImplementationA New Method on the Domain ModelOptionally: Unit Testing Event Handlers in Isolation with a Fake Message BusWrap-UpWhat Have We Achieved?Why Have We Achieved?
Commands and EventsDifferences in Exception HandlingDiscussion: Events, Commands, and Error HandlingRecovering from Errors SynchronouslyWrap-Up
Distributed Ball of Mud, and Thinking in NounsError Handling in Distributed SystemsThe Alternative: Temporal Decoupling Using Asynchronous MessagingUsing a Redis Pub/Sub Channel for IntegrationTest-Driving It All Using an End-to-End TestRedis Is Another Thin Adapter Around Our Message BusOur New Outgoing EventInternal Versus External EventsWrap-Up
Domain Models Are for WritingMost Users Aren’t Going to Buy Your FurniturePost/Redirect/Get and CQSHold On to Your Lunch, FolksTesting CQRS Views“Obvious” Alternative 1: Using the Existing RepositoryYour Domain Model Is Not Optimized for Read Operations“Obvious” Alternative 2: Using the ORMSELECT N+1 and Other Performance ConsiderationsTime to Completely Jump the SharkUpdating a Read Model Table Using an Event HandlerChanging Our Read Model Implementation Is EasyWrap-Up
Implicit Versus Explicit DependenciesAren’t Explicit Dependencies Totally Weird and Java-y?Preparing Handlers: Manual DI with Closures and PartialsAn Alternative Using ClassesA Bootstrap ScriptMessage Bus Is Given Handlers at RuntimeUsing Bootstrap in Our EntrypointsInitializing DI in Our TestsBuilding an Adapter “Properly”: A Worked ExampleDefine the Abstract and Concrete ImplementationsMake a Fake Version for Your TestsFigure Out How to Integration Test the Real ThingWrap-Up
What Now?How Do I Get There from Here?Separating Entangled ResponsibilitiesIdentifying Aggregates and Bounded ContextsAn Event-Driven Approach to Go to Microservices via Strangler PatternConvincing Your Stakeholders to Try Something NewQuestions Our Tech Reviewers Asked That We Couldn’t Work into ProseFootgunsMore Required ReadingWrap-Up
Env Vars, 12-Factor, and Config, Inside and Outside ContainersConfig.pyDocker-Compose and Containers ConfigInstalling Your Source as a PackageDockerfileTestsWrap-Up
Implementing a Repository and Unit of Work for CSVs
Repository Pattern with DjangoCustom Methods on Django ORM Classes to Translate to/from Our Domain ModelUnit of Work Pattern with DjangoAPI: Django Views Are AdaptersWhy Was This All So Hard?What to Do If You Already Have DjangoSteps Along the Way
What Is Validation, Anyway?Validating SyntaxPostel’s Law and the Tolerant Reader PatternValidating at the EdgeValidating SemanticsValidating Pragmatics

Overview

As Python continues to grow in popularity, projects are becoming larger and more complex. Many Python developers are taking an interest in high-level software design patterns such as hexagonal/clean architecture, event-driven architecture, and the strategic patterns prescribed by domain-driven design (DDD). But translating those patterns into Python isn’t always straightforward.

With this hands-on guide, Harry Percival and Bob Gregory from MADE.com introduce proven architectural design patterns to help Python developers manage application complexity—and get the most value out of their test suites.

Each pattern is illustrated with concrete examples in beautiful, idiomatic Python, avoiding some of the verbosity of Java and C# syntax. Patterns include:

Dependency inversion and its links to ports and adapters (hexagonal/clean architecture)
Domain-driven design’s distinction between Entities, Value Objects, and Aggregates
Repository and Unit of Work patterns for persistent storage
Events, commands, and the message bus
Command-query responsibility segregation (CQRS)
Event-driven architecture and reactive microservices