If multiple applications with limited functionality are interfacing with the db, then adding certain logic with procedures can be a good solution for consistency.

Procedures can be triggered by inserts/updates/deletes. This means logic can be replayed. There might be a table "IncomingActions" that triggers a set of procedures. Procedures might sanitize values on updates, update various specific materialized views.

Thinking about it generally, consider the db as storing system state, and a set of actions that updates the state. So the db is a sort of state machine, and the triggers/procedures define the reachable state space. For example, there might be FK constraints that forbid clients to insert into the table "Orders". Instead, clients could insert into "OrderRequests" which triggers a set of procedures that ensures the entry in "Orders" is legal. In this way, an ORM app could be allowed to create Orders without needing to call procedures, or knowing anything about what makes "Orders" legal. We also get a log in "OrderRequests".

Error handling is ugly though.