Marco Vellinga started his talk with train-related analogies and photos, which I of course liked. They have a big monolythic application. Like a big train: move one part (a locomotive) and the rest also moves. In an application you don't want that: if you make a change in one part of the application, you don't want to have to change lots of other parts. Decoupled is better.
With abstraction, for instance a user object with username, password and billing information, you can change the backend (splitting user and billing info, for instance) without needing to change anything in the frontend.
They created an abstraction layer containing
- core logic
- error handling
- data contracts
There isn't really support for such a layer in Django, so you have to build it yourself. This was a lot of work and took a couple of tries to get it right.
For (API) versioning they build their own function/class decorator to mark functions as "version 1" or "version 2". They're calling it versionary. It is kind of spooky, but it is fully tested and documented.
The main question: is it worth building? Well, it paid off instantly when they put it into production because they immediately found invalid data that was already in the system. Because the abstraction layer put all the validation in one place, all the data that previously slipped through was now found out :-)
Photo explanation: just a nice unrelated picture from the my work-in-progress german model railway