Removing business logic from transaction processing

If you are a fan of uncle Bob, you will not be strange to his idea of clean architecture, which basically says business logic is the core of any architecture design rather than frameworks or external systems such as database.

In the Agile world, one should maximise the decisions not made in terms of what database to use and even whether to use a database or not. Instead focus on prioritizing the business logic as much as possible. Because the rates of change of business logics is much less than technologies.

From this perspective, it makes little sense to encode business logic in stored procedures.

Another consideration one should take is the fact that normal programming languages are much more powerful than stored procedures. Considering modern languages such as Scala, it's much more concise, expressive and maintainable to put complex business logics in it rather than in stored procedure.

Lastly, perhaps most people omit is the concern of scalability. Transactional database is one of the most difficult components in your system to scale. The database is usually built with expensive special hardware tuned for transaction processing. Scaling such kind of system is going to be very difficult comparing to adding more Linux app server or web server or using cloud computing.

Are you convinced by now?