🤖▶️ Check out the Design Patterns Overview course by Steve @ardalis Smith!Check it out »Hide


Facade Pattern

Facade Pattern

The Facade Pattern is used when you want a simpler interface for a subsystem of a complex system. The complex system typically contains a code smell known as the big ball of mud that typically evolves from the blob. By using a facade, you create an interface that only shows the necessary endpoints for a subset of a system rather than the entire complex system.

Note: The subsystem does not know that the facade exists. There are ties from the facade to the subsystem, but not from the subsystem to the facade.

For example, suppose you have an eCommerce system with a monolithic API. The API has endpoints for orders, invoices, customer profiles, products, product categories, store locations, and more.

Monolith API with Get endpoints for the suggested entities.

Those are many subsystems. Some of those may be related, but having them all in one API violates the KISS and separation of concerns principles. Facades embrace simplicity.

Suppose you have a client that needs to maintain the products on the site. Create a facade that makes it so that the client uses a facade that only deals with products and product categories. The client does not need to know that the other sections exist in the big ball of mud.

Product Facade - with only Get endpoints for product management

By creating this facade, the client does not need to be concerned with customer IDs, order IDs, or invoice IDs.

Facade Pattern in terms of DDD

When it comes to domain-driven development, think of the Facade Pattern like this:

  • The domain - eCommerce - is too large to group all things into one API.
  • Subdomains - such as Orders, Invoices, and Products - provide logical groupings that may indicate where facades may be helpful.
  • Bounded contexts provide the boundaries - the limitations - of those facades.

See Also


Edit this page on GitHub

On this page

Sponsored by NimblePros