Facade

Facade gives a subsystem one simple front door. It is the easiest pattern to apply and the easiest to overgrow: the same instinct that produces a helpful entry point produces, three years later, a 2,000-line class that everything depends on.

The distinction that keeps it healthy: a facade simplifies access to a subsystem; it does not become the subsystem.

The problem

Placing an order legitimately involves several collaborators. Every caller currently orchestrates them.

// In the web controller, and again in the admin tool, and again in the CLI importer
const validated = validator.check(cart);
const priced = pricing.calculate(validated, customer);
const reserved = await inventory.reserve(priced.items);
const payment = await gateway.charge(priced.total, customer.paymentMethod);
const order = await orders.create({ priced, reserved, payment });
await notifications.orderPlaced(order);

Three callers now know the sequence, and the sequence is a rule — reserve before charging, notify after persisting. Duplicating it means three chances to get the order wrong and three places to edit when a step is added.

class OrderPlacement {
  async place(cart, customer) { /* the sequence, once */ }
}

What a facade is for, precisely

It removes duplicated orchestration. The value is that the sequence exists once, not that the call is shorter.

It names an operation in domain terms. placeOrder is a thing the business does. Six calls in a row is not.

It reduces the surface callers depend on. A controller that knew six collaborators now knows one, so refactoring any of the six does not ripple outwards.

It does not restrict access. This matters and is often misunderstood: a facade is a convenience, not a wall. If the underlying components remain public, callers may still use them directly — and sometimes should, for cases the facade does not cover. A facade that must be the only route is enforcing a boundary, which is a module or package concern rather than a class concern.

How it turns into a god object

The failure is gradual and each step is reasonable.

1. OrderPlacement.place() — clearly good.
2. Someone needs to place an order without notifying. A boolean parameter appears.
3. Someone needs to cancel an order. It goes here too — it is order-related.
4. Refunds, partial refunds, address changes, re-sends. All order-related.
5. The class is 2,000 lines, depends on eleven collaborators, and every feature touches it.

The failure is cohesion, not size. A facade should be defined by one entry point into a subsystem, not by a topic. "Everything about orders" is a topic, and topics grow without limit.

Two signals that it has happened:

• Boolean parameters that skip steps. place(cart, customer, { notify: false }) means the facade is serving two different operations and disagreeing with itself about what the sequence is.
• Collaborators used by only one method. If eight of eleven dependencies are needed by one method each, the class is a namespace, not an object.

Facade, service layer and adapter

These three overlap enough to be worth separating.

In practice an application service and a facade often look identical. The distinction worth keeping is that a service layer method is a use case with a transaction boundary and authorisation — it is where the application decides something — whereas a facade is a convenience over calls that could have been made directly.

When you do not need one

One caller. A facade over a sequence used in exactly one place is a function extracted for readability, which is good, but does not need a pattern name or its own class.

The sequence is not a rule. If callers legitimately vary the order or skip steps, freezing it into a facade will produce the boolean parameters described above.

The subsystem is already simple. Wrapping two calls in one saves a line and adds a file.

Check your understanding

Common mistakes

Organising by topic. "Everything about orders" grows forever; "one way into the order subsystem" does not.

Boolean parameters that skip steps. Two operations wearing one name.

A facade that everything imports. Coupling has been centralised, not reduced.

Assuming it enforces a boundary. A facade is a convenience; enforcement is a module or package concern.

A method per variation. Cover the common case and let unusual callers use the components underneath.

Wrapping something already simple. Two calls behind one is a file for a line.

Putting the domain rules in the facade rather than the domain. Orchestration is not the same as policy, and a facade that decides is a service layer that has not admitted it.

Practice

Key takeaways

• Facade provides one simple entry point to a subsystem; its value is that a multi-step sequence exists once, not that calls are shorter.
• It is a convenience, not a wall. Enforcing a boundary is a module or package concern.
• Define it by one entry point into a subsystem, never by a topic — "everything about orders" has no natural limit.
• Boolean parameters that skip steps mean two operations are hiding in one method.
• A facade imported by everything has centralised coupling, not reduced it. Split by operation.
• Distinguish it from Adapter (fits a pre-existing contract) and a service layer (use cases with transaction boundaries and authorisation).
• Skip it when there is one caller, when the sequence is not a rule, or when the subsystem is already simple.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002) — the service layer and its relationship to facades.
• Eric Evans, Domain-Driven Design (Addison-Wesley, 2003) — application services and module boundaries.
• Robert C. Martin, Clean Architecture (Prentice Hall, 2017) — use cases as the application's entry points.
• Kent Beck, Implementation Patterns (Addison-Wesley, 2007) — on cohesion as the organising principle for classes.