Change Impact Explorer
Pick a requirement change and see what it costs under two designs of the same system: how many modules you must edit, how far you must re-verify, which tests run, and whether the edit lands in one place. Every figure is a count read off a dependency graph, never a judgement about quality.
The claim this domain makes is that good design controls the cost of change, and this page is where that claim is made falsifiable rather than asserted. It is also where the claim is allowed to lose: work through every change below and you will find one where the tangled design edits fewer modules than the bounded one. That case is the most useful thing here. A design makes the changes it anticipated cheap; it cannot make every change cheap, and anybody who tells you otherwise has not tried to price one.
The change request
Eight things a business plausibly asks for. Two of them are much harder than they sound, and one of them is harder in the well-designed system.
What it costs, side by side
The same requirement, priced against a design that knows everything and a design where each piece of knowledge has one address.
The shape most systems reach after two years without deliberate boundaries: a single class that computes, persists, charges, notifies and audits, plus thin wrappers around the things it talks to.
Nothing beyond the edited modules.
The same system with each piece of knowledge given one address. Still one deployable unit — this is a modular monolith, not a set of services.
- — 2 more module(s) must be re-verified than edited, because they depend on something that moved.
The reading
Edits and re-verification are different sets, and the second is usually larger. Teams estimate the first.
The bounded design edits 1 module(s) against 3. This is a change the boundaries anticipated: the knowledge has one address, so the edit has one address.
How to read this page honestly
What the model is, and what it deliberately refuses to be.
- SIMULATEDThe two designs below are models written for this lab, not a real codebase. Every number on this page is a count read off a dependency graph you can inspect — modules that declare a reason to change, modules that depend on those, the test files those modules own. Nothing here is a quality number, because a design reduced to one would tell you nothing you could act on.
- CONTESTEDThe argument that boundaries are worth their cost is not universally accepted, and the strongest form of the objection is on this page rather than hidden from it: separation buys locality for the changes it anticipated and charges for the ones it did not. Pick a cross-cutting change below and the bounded design edits *more* modules than the tangled one. That result is the lab working, not the lab failing.