[HelloNurse]

> If you need to change something in the UI layer, it will likely ripple down through business logic layer into the storage layer. If you make a change in the storage layer, you could inadvertently end up changing your user-facing API and breaking something for them.

This sort of "rippling" should normally result from poorly thought out and excessively casual changes layered over previous bad design.

Changes coming from the UI layer should normally be new and altered ways to search and modify the same entities, with no changes to the core model and its storage.

Changes from the storage layer are unlikely (e.g. new indices or adjusted datatypes in a database) and should be handled by some persistence abstraction, with a very limited impact in the business logic and completely invisible and irrelevant for the UI layer.