Dependency Inversion and Decoupling

Open the Order domain module of a typical service and count the framework imports. In the unmanaged version, orders.py or Order.java imports the ORM session, the web framework's annotations, and the message-bus client directly: the class that encodes business rules has a compile-time dependency on three infrastructure packages. Every one of those arrows points the wrong way, and the costs arrive on a schedule.

# Before: policy depends on details
from sqlalchemy import Column, Integer   # ORM in domain
class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    def refund(self, amount): ...         # business rule

from kafka import KafkaProducer           # bus client in domain
class OrderEvents:
    def publish(self, order):             # policy calls infra directly
        KafkaProducer(...).send("orders", order.to_json())

The rules for swapping cannot hold a dependency: migrating from SQLAlchemy to a hand-rolled repository means editing domain classes; testing refund() requires a database session; upgrading the Kafka client's major version ripples into business logic. Dependency inversion makes domain code depend on interfaces rather than frameworks — and the principle is specifically about the direction of the source-code dependency, not about a Repository interface merely existing somewhere in the project.

Invert each arrow so the policy declares the abstraction it needs, and the infrastructure implements it:

# The abstraction lives with the policy (ports)
class OrderRepository(Protocol):
    def get(self, order_id: UUID) -> Order: ...
    def save(self, order: Order) -> None: ...

class OrderEventPublisher(Protocol):
    def order_placed(self, order: Order) -> None: ...

class PlaceOrder:                       # use case: pure policy
    def __init__(self, repo: OrderRepository,
                 events: OrderEventPublisher): ...
    def __call__(self, cmd: PlaceOrderCmd) -> Order:
        order = Order.place(cmd)
        self.repo.save(order)           # depends on the port
        self.events.order_placed(order)
        return order

# Adapters at the edge implement the ports
class SqlAlchemyOrderRepository:
    def __init__(self, session): self.session = session
    def save(self, order): self.session.merge(to_row(order))

class KafkaOrderEventPublisher:
    def order_placed(self, order): self.producer.send(...)

Read the imports now: PlaceOrder imports nothing from SQLAlchemy or Kafka; the adapters import both the ports and the frameworks. That is inversion — the low-level detail (the driver, the ORM, the SDK) now depends on the abstraction the policy defined, instead of the reverse. The rule of thumb that catches drift in review: if a package under domain/ or core/ imports anything named after a vendor or a framework, the arrow regressed.

Three consequences are worth naming because they are what you are buying. The policy compiles and loads without any infrastructure present — so the module can be unit-tested, reasoned about, and reused in a batch job with no web stack attached. Swapping a detail becomes an adapter exercise: replacing Kafka with SQS is a new adapter class plus one wiring change, and the use cases do not know. And the boundary makes performance decisions explicit, because mapping between the domain model and the persistence rows happens in one visible place (the adapter) instead of leaking ORM identity maps through business rules. The next chapter's Clean Architecture Layers generalizes this into a full ring structure; the same principle, one module at a time, already pays for itself. A useful sequencing detail for teams doing the inversion incrementally: do not attempt a big-bang re-plumb. Start with the port that hurts most — usually the repository behind the module with the worst test suite — extract the interface from actual call sites so it names the operations the policy truly uses, implement the adapter by wrapping the existing ORM code rather than rewriting it, and leave the next port for the following sprint. Three or four such inversions usually cover the module's real dependencies, and each one ships independently with the test-suite improvement visible immediately.

Once policy holds ports, something must connect ports to adapters at runtime. The choices differ more than they appear, and the differences are what interviews probe.

Constructor injection declares dependencies in the signature and freezes them at creation:

class PlaceOrderHandler {
  private final OrderRepository repo;      // immutable after ctor
  private final OrderEventPublisher events;

  PlaceOrderHandler(OrderRepository repo, OrderEventPublisher events) {
    this.repo = Objects.requireNonNull(repo);
    this.events = Objects.requireNonNull(events);
  }
}

Everything the class needs is legible in one place: a reader sees the complete dependency set without scanning method bodies, the fields are final, and construction without all dependencies is impossible — the type system enforces the wiring. Compare the alternatives, because each hides something. Setter injection makes construction a multi-step protocol (new Handler(); h.setRepo(r); h.setEvents(e);) where a half-initialized object is representable and every field must survive being null. Field injection (the typical DI-annotation pattern) hides dependencies behind reflection entirely, and forces framework context to construct anything testable. And the service locator — a container object passed around and queried (locator.get(OrderRepository.class)) — inverts nothing: it replaces compile-time dependencies with runtime ones, so a missing binding fails in production instead of at construction, and the class's true dependency list becomes invisible again.

The related decision is where the wiring happens. A composition root — one module (or a handful of entry points) where concrete adapters are chosen and passed into constructors — keeps all knowledge of the actual stack in one file. With three or five ports, hand-written wiring is shorter and more debuggable than any framework; the DI container earns its place when the graph has dozens of bindings, scoped lifetimes (a per-request session vs a singleton publisher), and conditional registration (a stub adapter in dev, a real one in prod). If you do adopt a container, treat it as construction-time infrastructure only: dependencies are resolved at the root and passed in, never queried from inside business logic — that keeps the policy portable between containers.

A practical caution about lifecycle, because it bites in production: injection wiring can hide singleton state. A KafkaOrderEventPublisher registered as a singleton must be safe for concurrent use across all handler instances; a per-request repository must not leak into a global scope. Writing the intended lifetime next to each binding (// singleton, thread-safe: no mutable fields) is cheap documentation that prevents the classic 'works in tests, races under load' failure. With the wiring settled, the payoff arrives in the next chapter's test suite: running the entire domain against in-memory fakes. A note on constructor arity, because reviewers reasonably object when signatures grow. If a use case needs eight constructor parameters, that is signal, not a reason to fall back to setters: the class usually bundles two or three responsibilities (the SRP smell arriving from the other direction) and wants splitting into two constructors' worth of collaborators. An optional knob like a clock or an id generator may legitimately default to the system implementation, but anything with observable behavior should stay explicit — a default that hides a real collaborator trades a long signature for a silent dependency.

The claim that dependency inversion improves testability deserves numbers, because the alternative is a test suite that teams learn to skip. In a typical unmanaged service, running the PlaceOrder scenarios means starting a Postgres container, a Kafka broker, and the migration tooling — 40 to 90 seconds per session, plus flaky-start failures a few times a week. Teams respond by running integration tests only before release. The inverted design removes that trade: the domain suite runs against fakes at the ports, in milliseconds, on every save.

The fake is not a mock. A mock verifies interactions; a fake implements the port's contract in memory so scenarios can be set up and asserted against real domain behavior:

class InMemoryOrderRepo:
    def __init__(self): self.rows = {}
    def get(self, oid):
        if oid not in self.rows: raise OrderNotFound(oid)
        return self.rows[oid].clone()      # preserve identity semantics
    def save(self, order): self.rows[order.id] = order.clone()

class RecordingEventPublisher:
    def __init__(self): self.published = []
    def order_placed(self, order): self.published.append(order.id)

def test_double_refund_rejected():
    repo = InMemoryOrderRepo(); events = RecordingEventPublisher()
    use_case = PlaceOrder(repo, events)
    order = use_case(PlaceOrderCmd(cart=[line("sku-1", 2)]))
    order.refund(order.total)
    with raises(RefundNotAllowed):
        order.refund(Money(1))            # domain rule, no infra in sight

The suite compiles and runs with no external process: a thousand tests in under a second, deterministic, debuggable with a plain stack trace. Two traps keep fakes honest, and experienced teams name them out loud. Semantic drift: the fake's save() overwrites while the real Postgres adapter upserts, or the fake returns the same mutable object the database would re-read fresh — so the fake must reproduce the contract's observable behavior (clone on read, raise the same not-found error), not merely its signature. The adapter gap: nothing in the domain suite proves the real SqlAlchemyOrderRepository actually persists — so each adapter keeps one thin contract test that runs the port's behavior checks against the real dependency in CI, while the fast suite stays pure.

The strategy question interviewers ask next is whether in-memory fakes 'really' test the system. The honest answer is layered: fakes give the domain suite its speed, contract tests keep the fakes truthful, and a small end-to-end tier proves the composition root wires the right adapters with the right configuration. Each tier exists because the one below it cannot see something — and the inversion is what made the tiers possible at all. One operational benefit teams discover late: the inverted domain suite changes how refactoring feels. With the suite against fakes, a developer can restructure the entire use-case layer and see deterministic pass or fail in a second, which encourages continuous structural improvement instead of frozen code. The unmanaged alternative trains the opposite habit — if validating a rename takes a coffee break while containers boot, developers batch changes and ship riskier diffs. Suite runtime is a process property, not just a testing detail: it shapes how aggressively the design is maintained.