Dependency Cycles

• Reasoning: answering "what happens when an order is voided" requires all three modules at once, because the call graph loops back on itself (Local Reasoning).
• Testing: constructing any one module requires constructing the other two, so every test uses mocks and the mocks encode the cycle (Testing as Design Feedback).
• Initialization: whichever module is constructed first holds a reference to a not-yet-finished one — a null field, a half-built singleton, or a lazy proxy that fails on first use (Initialization Races).
• Modularity: none of the three can be extracted, versioned or deployed separately until an edge is removed (Where the Boundary Goes).
• Deletion: none of the three can be deleted or replaced independently, which is the property most people mean by "modular" (Extract Module).
• Correctness, here specifically: the closing edge reads the order at send time, so a void between charging and sending produces a receipt for lines that no longer exist.

1. 1
   Pass data instead of a reference

   Billing builds a Receipt value and hands it to Notifications, which no longer needs Orders for anything. Fixes the stale-read bug at the same time.

   fails by The value grows into a copy of the order and drifts from it, so two shapes of the same thing now exist (Duplicate Knowledge).

2. 2
   Invert the direction

   Define the interface in the module the dependency should point away from, and let the other implement it. The call still happens; the compile-time edge reverses (Dependency Inversion).

   fails by The interface is placed in the wrong module and the cycle moves one hop rather than disappearing — check with the tool, not by eye.

3. 3
   Extract the shared concept

   If both genuinely need the same knowledge, give it its own module that both depend on.

   fails by The extracted module is a bucket rather than a concept, and becomes common — the highest-fan-in module in the codebase within a year (The Common Module).

4. 4
   Publish an event

   The producer announces that something happened and does not care who listens; the compile-time edge is genuinely gone.

   fails by The consumer cannot function unless the producer ran, so the dependency survives with no compiler, no signature and no way to find it (Observer).

5. 5
   Add the build rule

   Fail the build on any new cycle. Unambiguous, unlike a dependency count, and it is what stops this recurring (What to Automate Out of Review).

   fails by Applied to a legacy codebase with hundreds of existing cycles, it acquires an exemption list that becomes permanent (Deliberate Debt).

The first move is right here because the closing edge existed to fetch data. When the closing edge exists to *trigger* something instead, the second or fourth move is the honest one and the first will not apply.

// notifications.ts
import { orders } from './orders'          // the closing edge

export async function sendReceipt(orderId: OrderId) {
  const lines = await orders.getLineItems(orderId)   // read at send time
  await mail.send(renderReceipt(orderId, lines))
}

// A void between charge and send changes what the receipt says.
// A test for sendReceipt needs Orders, which needs Billing,
// which needs Notifications.

// receipt.ts — a value, no behaviour, no dependencies
export interface Receipt {
  orderId: OrderId
  chargedAt: Instant
  lines: readonly ReceiptLine[]
  total: Money
}

// notifications.ts
import type { Receipt } from './receipt'

export async function sendReceipt(r: Receipt) {
  await mail.send(renderReceipt(r))
}

// billing.ts already has everything the receipt needs
await notifications.sendReceipt(toReceipt(order, charge))

Three things change at once and they are the same change. The import disappears, so the graph is acyclic and Notifications can be constructed, tested, extracted and deleted on its own. The lookup disappears, so a void between charge and send can no longer alter what the receipt says — the value was captured at the moment it was true. And the test for sendReceipt now needs one struct instead of two modules, which is the clearest signal available that the boundary is finally in the right place (Testing as Design Feedback).