Breaking Cycles

1. 1
   Draw the graph

   Get the real edges from tooling rather than from memory, including transitive ones.

   fails by Arguing about a cycle nobody has actually seen, which is usually larger and differently shaped than assumed.

2. 2
   Name what travels the loop

   Write the sentence: which knowledge does each edge carry, and what is it really about?

   fails by Skipping to mechanism. Every fix below follows from this sentence, and without it the choice is arbitrary.

3. 3
   Build the safety net

   Characterization tests at a boundary that will not move during the refactor.

   fails by Refactoring heavily-used modules on the assumption that the existing tests cover the interaction (Refactoring Without Tests).

4. 4
   Choose the fix from the sentence

   A third concept means extract; one reason to change means merge; genuinely different rates of change mean invert.

   fails by Choosing by habit — which for most teams means an interface, regardless of what the sentence said.

5. 5
   Ship it in slices

   Extract or merge, migrate callers in separate merges, then delete the old edges.

   fails by One large branch across three heavily-used modules, which will not merge cleanly and will be abandoned (Incremental Migration).

6. 6
   Enforce and re-check

   Add the acyclicity check, then look at merge history six weeks later to see whether co-change actually dropped.

   fails by Declaring victory at the green build. The graph is the proxy; co-change is the thing (Change Amplification).

Steps two and six are the ones that distinguish a fix from a rearrangement, and both are cheap. Neither involves writing any code.

// order/Order.ts
import { OrderValidator } from './OrderValidator'
export class Order {
  place() { OrderValidator.check(this); /* ... */ }
}

// order/OrderValidator.ts
import { Order } from './Order'
export class OrderValidator {
  static check(o: Order) { /* reads six private-ish fields */ }
}

// Every rule change edits both files.
// Neither can be read or tested without the other.
// The split exists because "validation is its own concern".

// order/Order.ts
export class Order {
  place() {
    this.assertPlaceable()
    /* ... */
  }

  private assertPlaceable() {
    /* the same six checks, on its own fields */
  }
}

// One file. The rules sit next to the state they constrain,
// the cycle is gone, and there is nothing to inject or wire.

The two files had one reason to change — the rules for placing an order — and splitting them created a boundary that no change respected, plus a cycle to cross it. Merging removes the cycle, the indirection and one name, and it puts the invariant next to the state it protects, which is where it can actually be enforced (Where Invariants Live). The cost is a larger class and the loss of a seam: if order validation later needs to vary by market or by channel, that seam has to be re-created — and at that point it will be created against two real cases instead of a convention (The Rule of Three).