Why shouldn't the UI depend on business logic?

Because 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.