Dependency Inversion, Critically

// domain/PricingRules.ts
import { IPaymentGateway } from '../infrastructure/IPaymentGateway'
import type { Stripe } from 'stripe'          // <-- in the domain

@injectable()
export class PricingRules {
  constructor(@inject('IPaymentGateway') private gw: IPaymentGateway) {}
}

// container.ts — 240 registrations, ~15 with a real second impl
container.bind<IPaymentGateway>('IPaymentGateway').to(StripeGateway)

// Delete infrastructure/ and the domain does not compile.
// Uninstall the Stripe package and the domain does not compile.
// Nothing has been inverted.

// domain/PaymentGateway.ts   — declared by policy, in policy's words
export interface PaymentGateway {
  capture(amount: Money, ref: OrderRef): Promise<Settlement>
}

// domain/PricingRules.ts     — imports nothing outside domain/
import type { PaymentGateway } from './PaymentGateway'
export class PricingRules {
  constructor(private gw: PaymentGateway) {}
}

// infrastructure/StripeGateway.ts
import type { PaymentGateway } from '../domain/PaymentGateway'  // <-- the arrow

// Delete infrastructure/ and the domain still compiles and tests.
// Whether a container wires it is now irrelevant.

The load-bearing difference is which package declares the interface, and it is visible as one import line. In the right-hand version the domain has no knowledge that Stripe exists, so it compiles, tests and runs with the vendor package uninstalled — which is the property being bought, and it is worth having whether or not a second gateway ever exists. The decorators, the container and the registration count are orthogonal: the left-hand version has more of all three and none of the property.

• The right-hand column is checkable in about a minute with a grep and a build, and it is almost never checked (Dependency Direction).
• A codebase with no container at all can satisfy every cell in the right-hand column (Wiring and the Composition Root).
• If you have a container, keep it and fix the direction separately. They are independent decisions and treating them as one is how this went wrong originally.

• Problem it addresses — stable business policy that imports volatile detail cannot be compiled, tested or changed without that detail, so the most frequently changed code in the system is the hardest to exercise.
• Useful example — moving PaymentGateway into the domain package so the rules compile and test with the Stripe SDK uninstalled, and a vendor upgrade cannot alter a price.
• Misuse — installing a container, registering everything, generating an interface per class, and believing the graph has changed when it has not (How SOLID Gets Misused).
• Trade-off — a domain package that now carries port declarations, an architecture test that occasionally blocks an expedient change, and a frozen vocabulary that costs an N-implementation change when it turns out wrong.
• Counterexample — a small service whose "domain" is three hundred lines of transaction script over one database it will never leave, with a fast local Postgres in every developer's environment. Direct calls to the ORM are simpler, the tests are fast enough, and every port would be pure ceremony (Transaction Script, When Design Does Not Pay).

caveat These are relative positions on a specific codebase's concerns, not measurements, and the second and third rows swap places entirely on graph size — hand-wiring eight hundred objects is not simpler than a container by any reading. Nothing in the numbers captures the two variables that actually decide it: whether a fast local integration environment exists, which can make the top row genuinely correct, and whether the team can tell the difference between the last two rows at all, which is the real subject of this lesson.