I've personally been thinking about this for some time and wondering if in the real world this looks like building as much as possible at the database level and treating your DB as a state machine for your app, aiming to disallow whole classes of errors and communicating the design of the business logic at the SQL functions/triggers/data layer, separate from the API, Services, Programming Language, and Frontend layer(s).
This means that instead of lots of issues with business logic being separate from the data the business logic and data sit together and prevent your system from getting into bad states.
Thinking about this, maybe I just stole this thought from Derek Sivers: https://sivers.org/pg
Yes, the data model is probably the most important aspect of your application, it defines the relations and constraints. With a good data model, you don't need to write a lot of code to deal with it. Having lots of code that deals with weird situations in the database means your data model needs some serious consideration.
A database in my opinion is not a good place to write business logic with functions and triggers, since there is lack of tooling that would make development and debugging easy. Let the database do what it does well, which is storing and querying data.
This means that instead of lots of issues with business logic being separate from the data the business logic and data sit together and prevent your system from getting into bad states.
Thinking about this, maybe I just stole this thought from Derek Sivers: https://sivers.org/pg