Pycon NL: practical software architecture for Python developers - Henk-Jan van Hasselaar¶
(One of my summaries of the 2026 one-day Pycon NL conference in Utrecht, NL).
First some terminology. Cohesion and coupling for instance.
Cohesion means how much the elements in a module belong together. “Belonging together”: working towards the same goal or function. Watch out what your answer is: is there an “and” in the sentence. “This module reads data and puts it in the database”. That’s a sign of lower cohesion.
Cohesion also has to do with your mental load: what can you keep in your head at the same time?
Coupling. Basically the blast radius: how much breaks when you change an object.
Change. Not often talked about. Architecture is more than diagrams. Architecture actually is making future changes cheaper. No change, no pain.
Loose coupling, high cohesion is good. Tightly coupled, low cohesion is bad.
Python allows us lots of freedom. There is no enforcement of architectural boundaries. You have type hints, but they’re not enforced. Python’s basic assumption is that we’re all reasonable and responsible programmers.
Let’s look at an example problem. We have “the internet” that calls “our REST API” that stores stuff in “our database”. We start with a single function in our API that queries the database and returns the results. But then we want to uncouple the data and the presentation layer: some ORM around the database table that is called by the view function (=the original API function). All fine. But… when the database changes, the ORM layer changes and then the view function needs to change. Coupling, anyone?
How can we fix this? By having some sort of contract between the layers. A domain model in between. A change in the database means a change in the part of the code that creates the domain object, but the view function is unaffected.
But such a view function often also contains business logic. That often means you’re doing some talking to the database anyway. A normal approach is to put that part of the code into some “service” layer. You can also start writing adapters: convert the core domain models to some output format.
Closing remarks:
Your business rules deserve a home!
Put them somewhere the outside world can’t hurt them.
Unrelated photo from our Nelen&Schuurmans company trip to Cologne/Köln in Germany. Organ in the St. Aposteln church.