Architecture Patterns with Python: Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices

Practice makes less imperfect! And now back to our regular programming…

“architecture astronaut” nonsense

People do change their names, and their marital status, and even their gender, but we continue to recognize them as the same individual.

Harry and Bob do not recommend that you copy and paste our code into a production system and rebuild your automated trading platform on Redis pub/sub.

Be liberal in what you accept, and conservative in what you emit.

Even with well-tuned indexes, a relational database uses a lot of CPU to perform joins. The fastest queries will always be

Views do…raw SQL? (src/allocation/views.py)
<...>
Excuse me? Raw SQL?

If you’re anything like Harry encountering this pattern for the first time, you’ll be wondering what on earth Bob has been smoking. We’re hand-rolling our own SQL now, and converting database rows directly to dicts? After all the effort we put into building a nice domain model? And what about the Repository pattern? Isn’t that meant to be our abstraction around the database? Why don’t we reuse that?

No matter what we do, we’re always going to find that our software systems are inconsistent with reality, and so we’ll always need business processes to cope with these edge cases. It’s OK to trade performance for consistency on the read side, because stale data is essentially unavoidable.

This idea of trading consistency against performance makes a lot of developers nervous at first, so let’s talk quickly about that.

But if they’re not careful, they’ll end up producing the most chaotic mess of all: the distributed big ball of mud.