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

Architecture Patterns with Python. Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices Harry Percival, Bob Gregory - okladka książki

Autorzy:: Harry Percival, Bob Gregory
Wydawnictwo:: O'Reilly Media (Z chęcią przeczytam książkę w języku polskim)
Ocena:: Bądź pierwszym, który oceni tę książkę
Stron:: 304
Dostępne formaty:: ePub

Mobi

Ebook

169,14 zł ~~199,00 zł~~ (-15%)

29,90 zł najniższa cena z 30 dni

Dodaj do koszyka lub Kup na prezent Kup 1-kliknięciem

Poleć tę książkę znajomemu Poleć tę książkę znajomemu!!

Przenieś na półkę

Do przechowalni

Zostało Ci na świąteczne zamówienie

opcje wysyłki »

Najczęściej kupowane razem

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

Architektura aplikacji w Pythonie. TDD, DDD i rozwój mikrousług reaktywnych Harry Percival, Bob Gregory

TDD w praktyce. Niezawodny kod w języku Python Harry Percival

Cena zestawu: 320.45 zł

Zyskujesz: 56.55 zł (-15%)

Dodaj do koszyka

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

Wybrane bestsellery

O autorze książki

Harry Percival niegdyś był konsultantem specjalizującym się w zarządzaniu, później brał udział w pracach nad arkuszem kalkulacyjnym Resolver One. Pracował w PythonAnywhere LLP i promował metodykę TDD na konferencjach, warsztatach i innych wydarzeniach na całym świecie. Teraz pracuje w MADE.com.

Ebooka "Architecture Patterns with Python. Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices" przeczytasz na:

czytnikach Inkbook, Kindle, Pocketbook, Onyx Boox i innych
systemach Windows, MacOS i innych

systemach Windows, Android, iOS, HarmonyOS
na dowolnych urządzeniach i aplikacjach obsługujących formaty: PDF, EPub, Mobi

Masz pytania? Zajrzyj do zakładki Pomoc »

Oceny i opinie klientów: Architecture Patterns with Python. Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices Harry Percival, Bob Gregory

(0)

Szczegóły książki

ISBN Ebooka:: 978-14-920-5215-9, 9781492052159
Data wydania ebooka :: 2020-03-05 Data wydania ebooka często jest dniem wprowadzenia tytułu do sprzedaży i może nie być równoznaczna z datą wydania książki papierowej. Dodatkowe informacje możesz znaleźć w darmowym fragmencie. Jeśli masz wątpliwości skontaktuj się z nami sklep@ebookpoint.pl.
Język publikacji:: angielski
Rozmiar pliku ePub:: 7.5MB
Rozmiar pliku Mobi:: 20.1MB

Zgłoś erratę

Kategorie

Kliknij, aby zgłosić błędnie przypisaną kategorię »

Informatyka » Programowanie » Python
Idealne prezenty na Święta! » Prezenty dla Niego

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
- 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