My experience is with insurance, funds management and telco billing systems. Although every project is different, as a general rule I prefer to use stored proc

My experience is with insurance, funds management and telco billing systems. Although every project is different, as a general rule I prefer to use stored procedures to make changes to the data. The SPs are written to ensure data integrity. Of course, there are some very basic business rules evident at this level but the primary concern is the correctness of data as updated/inserted. I would characterise these as the "data integrity rules". Each SP encompasses a document, a test suite and the implementation. It goes through the DEV-TEST-UAT-PROD QA - promotion stepwise deployment. I see that as a reasonable substitute for continuous integration. The OO layer implements business rules. (The SPs are transactional/procedural). I consider the BRs as a lower level business logic. Then the application provides the high level business logic, e.g. validation, workflow, etc. In reference to your question, I generally end up with three layers, DB, BR (API), BL (app). Technically the DB also has an API, but that is only visible to the BR layer.