Knowing when to use the Facade Pattern

Suppose you are designing a system, and this system has a very large number of independent classes and also has a set of services to be implemented. This system is going to be very complex, so the Facade pattern comes into the picture and reduces the complexities of the larger system and simplifies interactions of the client code with a set of classes from a subsystem of the large complex system.

Suppose you want to develop a bank enterprise application with a large number of services to perform a task, for example, AccountService for getting the Account by accountId, PaymentService for payment gateway services, and TransferService for the amount transfer from one account to another account. A client code of the application interacts with all these services to transfer money from one account to another account. This is how different clients interact with the amount transfer process of the bank system. As shown in the following figure, here you can see client code that directly interacts with the subsystem classes and client also should aware about the internal working of subsystem classes, so it is simply a violation of the SOLID design principles because client code is tightly coupled with the classes of subsystem of your banking application:

Rather than client code directly interacting with the classes of a subsystem, you could introduce one more interface, which makes the subsystems easier to use, as shown in the following figure. This interface is known as a Facade interface, it is based on the Facade pattern, and it is a simple way to interact with the subsystems: