What signals tell you a facade has stopped helping and become a liability, and what would you do about each?

### Why facades decay A facade is a *judgement about what callers need*. Requirements move; the judgement ages. Unlike most patterns, a stale facade is not merely useless — it is actively expensive, because it is a second API that must be maintained, documented, tested and versioned. Recognising decay early is a senior skill. ### Smell 1 — the pass-through facade (1:1 mirror) ``` class OrderFacade { find(id) { return repo.find(id) } save(o) { return repo.save(o) } delete(id) { return repo.delete(id) } } ``` Every method forwards one call with identical parameters. Nothing was simplified; nothing was reordered; no default was chosen. The caller must still understand the subsystem exactly as before, and now there is a second file to update on every change. - **Why it happens:** cargo-culted layering ('every module must have a facade'), or a facade written before the subsystem was complex enough to need one. - **Diagnosis:** compare the number of subsystem types a caller needed *before* and *after*. If it is unchanged, it is not simplifying. - **Fix:** raise granularity — replace CRUD mirrors with intent methods (`placeOrder`, `cancelWithRefund`) that encapsulate multi-step sequences — or delete it. A thin pass-through is sometimes still justified *purely as a visibility boundary* (so internals can be hidden), and that is a legitimate reason; just be explicit that that, not simplification, is the value. ### Smell 2 — the god facade Symptoms: 30+ methods; a constructor taking 12 collaborators; unrelated concerns (billing + notifications + reporting) behind one type; the file everyone edits, so it is a merge-conflict hotspot; changes to it force recompiles/redeploys everywhere. - **Why it happens:** an opaque facade under pressure — every new need must go through it — combined with reluctance to create a second facade. - **Fix:** segregate by *client*, not by data. Ask 'who calls this, and for what job?' and give each answer its own narrow facade over the same subsystem. Multiple facades over one subsystem is normal and healthy. Alternatively, have one entry point return capability objects (`api.orders()`, `api.refunds()`), keeping discoverability without one flat surface. ### Smell 3 — leaky signatures The facade compiles, but its methods take and return internal types — JPA entities, ORM models, internal enums, library-specific exception types. Callers must import internals to call the facade, so the coupling reduction was illusory and the subsystem still cannot be refactored. - **Fix:** define boundary types (commands, DTOs, records) owned by the facade's own module, and map at the edge. Cost is real — mapping code and duplicated shapes — so apply it where the boundary matters (cross-team, published, or likely-to-change subsystems) rather than everywhere. - Related: leaking *exceptions*. If a facade over an HTTP library throws that library's exception type, swapping the library is a breaking change. Translate to your own error type. ### Smell 4 — the ignored facade Grep shows 6 uses of the facade and 90 direct uses of the subsystem. Either the facade solves the wrong problem (its methods do not match real tasks), or discovery failed (nobody knows it exists), or it is too restrictive and everyone routed around it. - **Fix:** derive the API from actual call sites — collect the top 10 sequences callers write and make those the methods. If after that it is still unused, delete it; an unused abstraction is pure carrying cost. ### Smell 5 — facade grows behaviour It starts computing prices, applying domain rules, or holding transactional state. That may be a perfectly good *application service*, but calling it a facade sets the wrong expectations (reviewers assume it is deletable and behaviourless). Rename it and treat it with the testing and design rigour a service deserves. ### Smell 6 — the cycle Subsystem classes import the facade or call back into it. This is definitionally not Facade any more (it is closer to Mediator), it breaks the one-way dependency rule, and it means the subsystem cannot be reused or tested without its own wrapper. Fix by inverting: pass what the subsystem needs as parameters or callbacks, or move the coordinating logic entirely into the facade. ### A pragmatic evaluation checklist 1. How many subsystem types does a typical caller name with the facade vs without? (Must drop.) 2. What is the ratio of facade methods to subsystem methods? (Near 1:1 → suspicious.) 3. Do facade signatures mention internal types? (Should not, at real boundaries.) 4. What fraction of call sites use it? (Low → wrong level or dead.) 5. Does anything in the subsystem reference the facade? (Must be zero.) 6. Is it growing flags/overloads faster than callers? (Split it.) ### The uncomfortable conclusion Sometimes the right action is deletion. A facade that is not reducing caller coupling or encapsulating a real sequence is negative-value code, and 'we might need the indirection later' is not a justification — the indirection can be reintroduced when a second caller or a real variation appears.