Suggest an editImprove this articleRefine the answer for “What happens if a facade becomes too "fat"?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)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. **Key point:** a good facade should coordinate the actions of subsystems, not control all of the logic.Shown above the full answer for quick recall.Answer (EN)ImageIf 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**.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.