Architecture Patterns with Python

Dependency Inversion Principle Applicationdesign lever

The degree to which high-level modules (domain, service layer) depend on abstractions rather than on concrete low-level infrastructure modules such as ORMs, email libraries, or HTTP frameworks. Operationalized as explicit abstract base classes or duck-typed interfaces between layers.

Domain Model Puritydesign lever

The extent to which domain model classes contain no direct imports of or dependencies on infrastructure concerns such as ORMs, web frameworks, email clients, or databases. A pure domain model consists solely of plain Python objects expressing business rules and concepts.

Repository Pattern Adoptiondesign lever

The use of a repository abstraction that hides persistent storage details behind a simple add/get interface, allowing the domain and service layers to be tested without a real database by substituting an in-memory fake repository.

Service Layer Adoptiondesign lever

The presence of a dedicated orchestration layer that defines use-case entry points, coordinates repositories and domain services, handles transactions via the Unit of Work, and presents a technology-agnostic API to entrypoints such as Flask or CLI tools.

Unit of Work Pattern Adoptiondesign lever

The use of a Unit of Work abstraction that manages atomic database transactions, provides access to repositories within a single context, and collects domain events for publishing, decoupling service functions from session management.

Aggregate and Consistency Boundary Designdesign lever

The degree to which the domain model is organized around well-chosen aggregates that act as single entrypoints for modifying related objects, enforce invariants within their boundary, and constrain the scope of each database transaction to one aggregate.

Event-Driven Design Adoptiondesign lever

The extent to which the system models significant business occurrences as explicit Domain Event objects, uses a Message Bus to route events to handlers, and treats both internal workflows and external integrations as event-processing pipelines rather than direct method calls.

CQRS Adoptiondesign lever

The degree to which read operations are served by separate, simplified read models or raw SQL views rather than forcing the write-optimized domain model to serve query needs, reducing complexity and enabling independent scaling of reads and writes.

Dependency Injection and Bootstrappingdesign lever

The practice of explicitly declaring all external dependencies (UoW, email, message publisher) as function or class parameters and wiring them together in a single bootstrap script, enabling easy substitution of real and fake implementations across entrypoints and tests.

Test Pyramid Shapebehavioral pattern

The distribution of automated tests across unit, integration, and end-to-end levels, with a healthy pyramid having many fast unit tests, fewer integration tests, and very few end-to-end tests. An inverted pyramid (ice-cream cone) indicates over-reliance on slow, brittle tests.

Infrastructure Couplingpsychological state

The degree to which business logic modules are tightly coupled to specific infrastructure choices such as a particular ORM, web framework, database engine, or messaging library, making it expensive to change any infrastructure component without modifying business logic.

Global Code Coupling (Big Ball of Mud)contextual condition

The overall degree of entanglement among modules in the codebase, characterized by homogeneity of function across layers, business logic scattered across web handlers and model classes, and dependencies that make changing any component risky and expensive.

Domain Model Expressivenesspsychological state

The degree to which the domain model code reads in the language of the business domain, uses ubiquitous language for class and method names, and serves as living documentation that non-technical stakeholders could validate, making the model a faithful representation of business rules.

Testabilitypsychological state

The ease with which individual components of the system can be exercised in isolation with fast, deterministic tests that do not require real databases, email servers, or HTTP services, enabled by well-defined abstractions and injectable fake dependencies.

Consistency and Invariant Enforcementbehavioral pattern

The degree to which the system reliably prevents invalid states—such as over-allocation of stock or double-booking—through a combination of aggregate boundaries, version numbers for optimistic locking, and transaction isolation, even under concurrent load.

Inter-Service Couplingcontextual condition

The degree to which separate services or subsystems depend on one another synchronously and directly (high coupling, e.g., synchronous HTTP RPC chains) versus communicating through asynchronous events with no direct dependency on each other's availability (low coupling).

System Maintainabilityoutcome metric

The long-term ease of modifying, extending, and refactoring the codebase in response to changing business requirements without introducing regressions, measured by the cost and risk of making changes as the system grows in size and complexity.

Delivery Speed and Agilityoutcome metric

The rate at which the team can safely ship new features and bug fixes, influenced by test suite speed, confidence from automated tests, and the ease of reasoning about the impact of a change in a well-structured codebase.

System Reliability and Resilienceoutcome metric

The ability of the system to continue functioning correctly and to recover gracefully when individual components fail, enabled by small atomic transactions, independent failure of event handlers, retry logic, and eventual consistency between aggregates.

Read Performance and Scalabilityoutcome metric

The speed and horizontal scalability of query operations, improved by separating read models from the write-optimized domain model, using denormalized views or caches, and avoiding SELECT N+1 patterns inherent in ORM-based domain traversal for reads.