Facade Pattern: Simplify Complex Subsystems with a Unified Interface

1. The Problem Without a Facade

When placing an order, a controller must directly coordinate several subsystems: InventoryService, PaymentService, LogisticsService, and NotifyService. The article shows a concrete OrderController implementation that manually calls each service, handles rollback on failure, and builds the logistics record.

Issues identified:

The caller knows too much about four subsystems, their APIs, and the required call order.

The orchestration logic is duplicated wherever an order is created (e.g., pre‑order, flash‑sale).

Any change in a subsystem forces changes in every caller.

2. Introducing the Facade

The Facade pattern creates a single class that holds references to all subsystems and encapsulates the whole workflow in one method. The article provides a complete OrderFacade implementation that injects the four services (typically via Spring) and offers a placeOrder method.

public class OrderFacade {
    private final InventoryService inventoryService;
    private final PaymentService paymentService;
    private final LogisticsService logisticsService;
    private final NotifyService notifyService;

    public OrderFacade(InventoryService inv, PaymentService pay,
                       LogisticsService logi, NotifyService notify) {
        this.inventoryService = inv;
        this.paymentService = pay;
        this.logisticsService = logi;
        this.notifyService = notify;
    }

    public String placeOrder(long userId, long skuId, int count,
                            double amount, String address) {
        if (!inventoryService.deduct(skuId, count)) {
            throw new RuntimeException("库存不足");
        }
        if (!paymentService.pay(userId, amount)) {
            inventoryService.rollback(skuId, count);
            throw new RuntimeException("支付失败");
        }
        String logisticsNo = logisticsService.ship("NO123", address);
        notifyService.sendSms(userId, "您的订单已创建");
        return logisticsNo;
    }
}

Now the controller only depends on OrderFacade and calls orderFacade.placeOrder(...).

3. Comparison and Benefits

The article highlights the clear upgrade: the caller goes from “knowing 4 subsystems + call order + handle rollback” to “knowing 1 facade + invoking 1 method”. All complex coordination is confined to the facade, which can be reused wherever an order is needed.

4. Facade and the Law of Demeter

The Facade directly implements the Law of Demeter (least knowledge principle). Without a facade, OrderController talks to four strangers; with a facade, it talks only to its direct friend OrderFacade, which knows nothing about the controller.

5. Facade Is Not a Barrier

The pattern provides a convenient default path but does not forbid direct subsystem access when special needs arise. The article gives an example where a maintenance tool bypasses the facade to call inventoryService.deduct() directly.

6. Distinguishing Facade from Similar Patterns

Facade vs Proxy : Proxy shares the same interface as the real object and controls access; Facade defines a brand‑new, simpler interface and usually coordinates multiple subsystems.

Facade vs Adapter : Adapter converts one existing interface to another; Facade invents a new interface to simplify a group of subsystems.

Facade vs Mediator : Facade is a one‑way direction (caller → facade → subsystems); Mediator enables two‑way communication among colleagues.

7. Real‑World Appearances

Common library examples that act as facades:

SLF4J Logger – a unified logging API that hides Logback, Log4j2, etc.

Spring JdbcTemplate – wraps the verbose JDBC workflow into simple query() and update() methods.

Spring RestTemplate and JmsTemplate – similar simplifications for HTTP and messaging.

SDK client classes (e.g., XxxClient) – encapsulate authentication, signing, retries, and network calls behind a single method.

8. When to Use a Facade

Signals that indicate a facade is appropriate:

An operation must coordinate multiple subsystems and the workflow is reused in many places.

You want to expose a simple, external entry point for a complex module.

You aim to decouple callers from subsystem internals, especially in layered architectures.

Two common misuses to avoid:

Turning the facade into a “God class” that contains business logic, violating single‑responsibility.

Creating a facade for a trivial subsystem where a direct call would be clearer.

9. Summary

The Facade pattern offers the most straightforward way to wrap a tangled set of subsystems behind a single, easy‑to‑use interface. It reduces coupling, aligns with the Law of Demeter, and appears in many mainstream libraries. Use it when coordination complexity exists, but keep the facade focused on orchestration, not on embedding all business logic.