What happens if a facade becomes too "fat"?

If a facade becomes too "fat" - that is, it takes on too many responsibilities - it turns into a "god object", and this leads to a number of architectural problems.

---

#1. Violating the Single Responsibility Principle (SRP)

The facade starts managing everything: business logic, data, errors, transactions. As a result, it stops being an interface and becomes the center of all the system's logic, which makes the code hard to maintain and brittle.

---

#2. Reduced Modularity

If too many components depend on a single facade, any change to it starts breaking dependent modules. The facade then turns into a point of tight coupling rather than isolation.

---

#3. Harder Testing

When a facade manages too many subsystems, testing it in isolation becomes nearly impossible: you have to spin up half the application.

---

#4. Loss of Transparency

All the logic ends up hidden "behind the facade", and it becomes hard to understand what is really happening under the hood. This complicates debugging and makes the system's behavior less predictable.

---

#5. Slower System Evolution

Because of the high coupling and volume of code, any new scenario requires changes precisely in the "facade", which contradicts the open/closed principle (OCP).

---

#How to Avoid It

• Split facades by context (for example, UserFacade, PaymentFacade, ReportFacade).
• Keep only coordination of actions in the facade, not business logic.
• Make sure the facade stays an interface, not a "mini-monolith".

---

Summary: A "fat" facade stops simplifying the system: it complicates it, creates a new dependency point, and breaks architectural isolation. A good facade should coordinate, not control everything.