Suggest an editImprove this articleRefine the answer for “Why shouldn't the UI depend on business logic?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**The UI is just a way to display data**, while business logic is the meaning of that data; when the interface depends on the logic, the two become tightly coupled, and a change to one breaks the other. **Key point:** the UI should depend on abstractions of the business logic (for example, `IUserService`), not the other way around, which lets the UI change without touching the core.Shown above the full answer for quick recall.Answer (EN)ImageBecause **the UI is just a way to display data**, while **business logic is the meaning of that data**. When the interface depends on the logic, the two become **tightly coupled**, and a change to one breaks the other. Here are the key reasons: --- ### 1. **Business logic must be independent of how it is displayed** The UI can be a web page, a mobile app, or a voice interface, while the business rules stay the same. If logic is "baked into" the UI, the code cannot be reused in other interfaces and has to be duplicated. --- ### 2. **The UI changes often, business rules rarely do** Design, frameworks, and UX patterns become outdated every couple of years. If the UI depends directly on the logic, every visual update becomes a risk to the business mechanics (for example, calculations, validation, checks). --- ### 3. **Testability** Business logic that does not depend on the UI is easy to test with unit tests, without a browser, buttons, or interfaces. If the logic is embedded in the UI, it can only be tested through end-to-end tests, which are slow and brittle. --- ### 4. **The Dependency Inversion Principle (the D in SOLID)** The UI should depend **on abstractions of the business logic**, not the other way around. This keeps the system flexible: the logic defines interfaces (for example, `IUserService`), and the UI simply uses them. This way the UI can change without touching the core. --- ### 5. **Resilience to change** If you decide tomorrow to switch from React to Flutter, the UI can be rewritten without touching the use cases and the domain. But if they are directly coupled, the whole application has to be redone. --- **Conclusion:** The UI is the system's "clothing." Business logic is its "body." If the "clothing" starts controlling how the organs function, the body will not survive long.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.