Comparisons
Pairs that get conflated in real conversations and in real pull requests — coupling and cohesion, abstraction and indirection, refactoring and rewriting, debt and mess. Neither column wins; what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.
Refactor vs Rewrite
The rewrite is chosen for a reason nobody says out loud: it is more pleasant. Reading someone else's tangled code is miserable and writing new code is fun, so the argument arrives dressed as engineering — "it will be cleaner", "it will be faster to build than to untangle" — when the honest version is a preference. What that framing hides is that the expensive part of a rewrite is not writing the code, it is the migration: the behaviour nobody documented, the customers depending on a bug, the data that must move without loss, the integrations built against the old shape, and the fact that the old system keeps receiving feature requests during the eighteen months you are not shipping. The second-system effect compounds it, because the rewrite is also where the team puts everything they wished they had built. That said, the anti-rewrite position is sometimes cited as an absolute, and it should not be: when the runtime is out of support, when the data model cannot express the current domain, or when the original is small enough to specify completely, a rewrite is the cheaper path. The deciding question is never which code is nicer. It is whether the current behaviour can be characterized, and whether old and new can coexist while you move.
Whenever the current behaviour is valuable and partly undocumented, whenever the system must keep receiving changes during the work, and whenever you can find a seam to work behind. Which is most of the time.
When the platform itself is the constraint — an unsupported runtime, a language nobody will maintain, a data model that cannot represent the domain you now have — and the current behaviour is either small, well specified, or genuinely being replaced rather than reproduced.
| Dimension | Refactor — change the structure incrementally, behaviour preserved, shipping throughout | Rewrite — build a replacement and cut over |
|---|---|---|
| Ships value | Continuously, in every increment | Once, at the end, if the end arrives |
| Risk profile | Many small, individually revertible risks | One large, hard-to-revert risk at cutover |
| Undocumented behaviour | Preserved by construction; characterization tests prove it | Must be rediscovered, usually from incidents after launch |
| Feature work during it | Continues in the same codebase | Must be done twice, or frozen — both are expensive |
| Stopping halfway | Leaves the system better than it was | Leaves two systems and no owner |
| Honest precondition | A seam exists, or one can be made | The behaviour is specifiable, and coexistence is possible |
| Team appeal | Low — it is archaeology | High, which is why the estimate is optimistic |
| Middle ground | Strangler: incremental replacement, which is a rewrite delivered as refactors | Partial rewrite of one bounded component behind a stable interface |
The same question, five structures
Layered, hexagonal, clean, vertical slice and modular monolith — compared without naming a winner, and with the block that says where the comparison stops being true.
A tidy table implies an equivalence that does not exist. These are not five points on one axis: layered, hexagonal and clean are statements about dependency direction; vertical slice is a statement about directory grouping; modular monolith is a statement about deployment and module visibility. Most real systems combine several. The where this comparison misleads block on every row is the part worth reading, and it is the reason this page names no winner — none of these is mandatory, and a team that adopts one because a diagram was pretty has skipped the only question that decides it.
These are not five points on one axis. Layered, hexagonal and clean are all statements about *dependency direction*; vertical slice is a statement about *directory grouping*; and modular monolith is a statement about *deployment and module visibility*. You can — and most real systems do — combine several of them: a modular monolith whose modules are vertical slices, each with a hexagonal boundary at its edges. Comparing them as alternatives is the single most common way this table is misread.
The word complexity is doing two jobs here. Layered and vertical slice are cheap to *set up* and can be expensive to *live in* once the codebase is large; clean and hexagonal are expensive up front and their cost is roughly flat afterwards. Any comparison made at week one inverts the ranking you would get at year three, and neither reading is dishonest — they are answering different questions.
Locality is a property of whether the boundaries match the change history, not of the style name. A vertical slice cut along the wrong capability lines has terrible locality, and a layered codebase with only one real feature has perfect locality. The only honest way to compare these columns is to open the last thirty merged changes in your own repository and count the directories each one touched.
Every column here is a claim about *fast tests without infrastructure*, and any of the five achieves that as soon as dependencies are injected rather than constructed — which is a separate decision none of these styles owns. What differs is the default test boundary each one nudges you toward, and that matters more than the theoretical maximum: layered nudges toward class-level tests with mocks, vertical slice toward feature-level tests, and the difference shows up in how much your suite has to change during a refactor.
The columns are answering to different pressures: hexagonal responds to *external* volatility, clean to *domain* richness, vertical slice to *feature count*, and modular monolith to *team count*. A system can score high on one pressure and low on the rest, which is why picking a style from a comparison table rather than from your own pressures is how teams end up with four rings around a CRUD application.
Team fit is not a tiebreaker, it is often the deciding factor, and it is the one this table cannot capture. A structurally superior design that the team will not maintain under deadline degrades into the worst version of itself — half-applied clean architecture, with some code respecting the ring rule and some not, is harder to work in than consistent layering. The right question is which of these your team will still be following in eighteen months.
This row compares familiarity, not intrinsic difficulty, and familiarity is a property of the industry at a moment in time rather than of the design. Layered wins here largely because it is what most people have seen, which is an argument for it and also the reason it is over-applied. It is also worth separating cost-to-read from cost-to-contribute-correctly: vertical slice inverts on those two, and the table's single number hides it.
Ceremony is only waste when the feature did not need it, and every column here is right for some features and wrong for others in the same codebase. That is the actual finding of this row: a uniform ceremony level applied to every feature guarantees you are overpaying on the simple ones or underpaying on the complex ones. Allowing different features to carry different amounts of structure is more valuable than choosing which column to standardise on.
shared/ directory that grows back under a new name, or slices that each reimplement infrastructure slightly differently.Every one of these degradations is the style's own strength taken past the point where it repays — which is why none of them can be called wrong, and why §138 forbids teaching any as mandatory. What makes a codebase bad is not the column it started in but the absence of anyone asking whether the structure still matches the changes arriving. The right comparison to make is between your current structure and your last thirty changes, not between two names on a page.