A crucial element of architecting a software application for scale is the collaboration of domain experts and developers. For that to happen, the application must separate the domain layer— where elements that represent the real world reside—from the infrastructure layer—where these elements are translated into precise software processes.

Within the Fintech team at Kiwi.com, we are rearchitecting a critical service to accept more payment providers. As part of this refactor, we are adopting the Unit of Work pattern to disentangle domain entities from the database processes that represent them. This way, domain experts can share their knowledge with developers more easily, and developers can find opportunities for optimization without the involvement of domain experts in the process.

Attendees will gain a solid understanding of how to implement the UoW pattern in their Python applications, how it fits into the broader context of DDD, and how to prepare their code for future growth.

As developers modelling a domain into a software product, how can we make the most of the insights that we receive from domain experts? Crucially, a system that reads similar to how domain experts talk and think about their area of expertise enables the team to look at the codebase as a whole, and not as a mix of modules.

But in order to do that, the system must be designed in such a way that what’s relevant to the domain takes a centre stage, and implementation details stay in the background. In order to do that, we can layer the codebase so that the domain—where elements that represent the concepts and interactions that domain experts talk about— is clearly delineated from the infrastructure—where these elements find a way to be implemented in purely software engineering terms.

At Kiwi.com, we are redesigning one of our most critical services in order to expand the number of payment providers that we are integrating with, enabling us to serve a bigger and more diverse pool of customers. As part of this redesign, we are making use of the Unit of Work pattern, with which the interaction between domain entities gets abstracted from the specifics of the database in which those interactions are recorded. Much has been said about the use of abstracting elementary domain objects into a clean data model, but it is the very interaction between those objects where, in practice, the delineation between the domain and the infrastructure layer collapses.

In this talk, we will cover the limitations of ORMs as a way to abstract the database details from the rest of the application, and will introduce the Unit of Work pattern to address those limitations. By means of real-world examples, the attendees will learn the advantages and trade-offs that the UoW pattern was designed to overcome, and will come away with practical use cases in which this pattern makes applications cleaner and more future-proof. The outline of the talk is the following:

1. Introduction, or “ORMs are the Vietnam of Computer Science” (5min) a. Impedance mismatch - Code and Database b. Impedance between Domain and Code c. Domain Driven Design
2. Understanding the Unit of Work pattern (5min) a. Definition and purpose b. Trade-offs
3. Advantages of UoW (5min) a. Isolation of data access from business logic b. Polyglot persistence
4. UoW in the wild (10min)