CodingBowl

You’ve mastered the core 10 patterns, but there is one final "Boss Level" pattern used in high-stakes enterprise systems. When a single business action involves updating three different repositories, applying two specifications, and running a command, you cannot risk a partial failure. The Unit of Work (UoW) Pattern acts as the conductor, ensuring that every change in a complex business flow succeeds or fails as a single, atomic unit.

The Business Use Case: A Banking Transfer

Imagine a money transfer between two accounts. You must:

1. Deduct funds from Account A (Account Repository).
2. Add funds to Account B (Account Repository).
3. Create a ledger entry (Log Repository).
4. Update the user's loyalty points (User Repository).

If the system crashes after step 2 but before step 3, your books won't balance. You need a way to wrap these independent Repository calls into one safe "unit" of change.

The Problem: The "Leaky" Transaction

In standard Django, we often see transaction.atomic wrapped around service logic. However, this forces your business logic to know about database transactions, making it harder to test and move away from the ORM.

# The "Bad" Way: Manual transaction management in the service
def transfer_funds(from_id, to_id, amount):
    # This is "leaky." The service layer is now managing DB plumbing.
    with transaction.atomic():
        sender = AccountRepository.get(from_id)
        receiver = AccountRepository.get(to_id)
        
        sender.balance -= amount
        receiver.balance += amount
        
        AccountRepository.save(sender)
        # If an error happens here, the log entry is never created,
        # but the balances might have already been updated in memory.
        LogRepository.add_entry(f"Transfer of {amount} from {from_id} to {to_id}")

---

The Solution: The Unit of Work Pattern

The Unit of Work keeps track of every object you’ve touched. It acts as a context manager that only "commits" to the database at the very end of the block. If any error occurs, it triggers a rollback for everything.

Step 1: Define the Unit of Work

We create a context manager that provides access to all necessary repositories and manages the transaction lifecycle.

# uow.py
from django.db import transaction

class UnitOfWork:
    def __enter__(self):
        # The UoW provides the repositories
        self.accounts = AccountRepository()
        self.logs = LogRepository()
        transaction.set_autocommit(False) 
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type:
            self.rollback()
        else:
            self.commit()
        transaction.set_autocommit(True)

    def commit(self):
        transaction.commit()

    def rollback(self):
        transaction.rollback()

Step 2: The New Workflow (Atomic and Clean)

The Service Layer no longer calls .save(). It simply modifies the domain entities. The UoW ensures everything is persisted only when the block finishes successfully.

# services.py
from .uow import UnitOfWork

def transfer_funds_service(from_id, to_id, amount):
    # The UoW handles the "How" of saving; the service handles the "What"
    with UnitOfWork() as uow:
        sender = uow.accounts.get(from_id)
        receiver = uow.accounts.get(to_id)
        
        sender.withdraw(amount)
        receiver.deposit(amount)
        
        uow.logs.add_entry(f"Transferred {amount}")
        # At the end of this 'with' block, the UoW commits everything!

---

Why it's Better for Big Projects

• Absolute Data Integrity: It is impossible to have a "partial success." The system is either 100% updated or 0% updated.
• Better Performance: The UoW can optimize database hits by batching multiple updates into a single transaction at the very end.
• Perfect for Testing: You can create a "MockUnitOfWork" that uses in-memory lists instead of a database, allowing you to unit test complex business flows in milliseconds.

---

This pattern is the "glue" that holds an enterprise-grade Django application together. By combining the Unit of Work with Repositories and Mappers, you've moved beyond basic web development into the realm of true Software Architecture.

Architecture Note: In a production environment, you might use a library like SQLAlchemy which has a built-in Unit of Work (the Session object). If you are using Django's ORM, building this thin UoW wrapper is the best way to keep your service layer clean and your business transactions safe.