Facade Pattern
Facade: start from the problem
See the responsibilities
A report download requires formatting, storage and an audit record. Every caller currently has to know the correct sequence and the details of each subsystem.
This is a structural pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Facade addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Facade offers a focused, simpler interface to a larger subsystem. It delegates to the underlying components and presents a useful operation to clients. The components can still exist behind that interface; the facade does not have to replace all their capabilities.
Our ReportFacade coordinates a small synchronous sequence. Its create operation returns the stored report reference after formatting and an audit call. It is a convenience boundary, not proof that three external services commit atomically.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const formatter = {format: text => 'REPORT ' + text};
const storage = {save: text => 'saved:' + text};
const audit = {record: () => 'recorded'};
const reportFacade = {
create(text) {
const reference = storage.save(formatter.format(text));
audit.record(reference);
return reference;
}
};
console.log(reportFacade.create('sales'));Expected output
saved:REPORT salesChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when callers need a stable entry point for a common subsystem workflow. Name errors and partial outcomes when the workflow spans independent effects.
A facade can grow into an unrelated catch-all service. Hiding component detail must not hide meaningful latency, permissions or partial failures. Keep the operation contract small and explain what success means.
Distinguish the neighbouring patterns
Adapter reconciles interfaces. Facade simplifies access to a subsystem. Gateway Aggregation combines remote responses, which adds network and partial-failure obligations beyond a local facade.
Follow Adapter’s compatibility boundary, combining remote responses, cross-service effects to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Facade, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside cross-service effects.
Reaching the recap and completing the quizzes are separate milestones.