A facade allows to adapt a type to its context of use.

As we have seen, a type describes a business object in all its richness (for example a customer with his name, his address but also his contacts, his means of payment, his invoices...).

In practice, an API or a message generally only takes into account a part of the data of an object. For example, a customer with just his name and address

The definition of a facade on the customer type will allow to realize this operation by retaining only the desired fields. If necessary, other transformations can be made to adapt the type more strongly to its context of use (renaming certain fields, modifying the data structuring, adding fields ...).


For example for the following modeling of a customer ( the graph has been slightly simplified for the example )

We could define the following facade :

facade CustomerDTO on Customer{

As we can see, we have defined a new very simple Customer representation that could be used to describe the content of an API or message.

This is a simple example, the associated article "How to describe a facade" will show you how to go further in the description of facades