Architecture Patterns with Python

Part I. Building an Architecture to Support Domain Modeling

Most developers have never seen a domain model, only a data model.

Cyrille Martraire, DDD EU 2017

Most developers we talk to about architecture have a nagging sense that things could be better. They are often trying to rescue a system that has gone wrong somehow, and are trying to put some structure back into a ball of mud. They know that their business logic shouldn’t be spread all over the place, but they have no idea how to fix it.

We’ve found that many developers, when asked to design a new system, will immediately start to build a database schema, with the object model treated as an afterthought. This is where it all starts to go wrong. Instead, behavior should come first and drive our storage requirements. After all, our customers don’t care about the data model. They care about what the system does; otherwise they’d just use a spreadsheet.

The first part of the book looks at how to build a rich object model through TDD (in Chapter 1), and then we’ll show how to keep that model decoupled from technical concerns. We show how to build persistence-ignorant code and how to create stable APIs around our domain so that we can refactor aggressively.

To do that, we present four key design patterns:

• The Repository pattern, an abstraction over the idea of persistent storage

• The Service Layer pattern to clearly define where our use cases begin and end

• The Unit of Work pattern to provide atomic operations

• The