It seems to me that much software can use a layered approach to get the best out of both systems. For example, in LedgerSMB, we use a highly engineered database on PostgreSQL, which means we can make the code "obviously correct" with regard to a number of invalid data bugs. We can then assign security to API operations declaratively using SQL roles. This makes the code obviously correct for certain classes of security issues and helps to mitigate other classes of security issues (for example SQL injection).

One of the key things to understand though is that "obviously correct" is always relative. There are, in fact, ways to circumvent these measures, and understanding where the problem areas lie. This means that most of the code may be "obviously correct" and some may be a bit less so. Knowing where that code is allows one to spend review time there.

The application above is written in Perl. However we are moving to Moose because it gives us a better ability to declare data constraints there.

I guess I'd call it "declaratively correct" instead of "obviously correct."