I agree 98% with this article, but as an architect we should never say never. There are circumstances when you would absolutely place business logic in a stored

I agree 98% with this article, but as an architect we should never say never. There are circumstances when you would absolutely place business logic in a stored procedure. You start with domain driven design, but there are many use cases that involve processing large amounts of data as quickly as possible. If you haven't read about "set theory", then you should. It boils down to math when you say you want to execute a function or set of functions on a large dataset as efficiently as possible. I've seen very complicated stored procedures that modify large amounts of data where the performance would degrade significantly outside of the database. But we should start with building a domain model and manage storage and performance as secondary interests. If, as we're designing our domain we see a lot of areas for high performance requirements, leveraging an engine (database or other) is a critical choice. But in general, we should not be placing code in SQL. The domain of writing and reading business logic belongs in a standard programming language, not a data-oriented programming language.