In the 90s and early 00s I worked on applications where the bulk of the business logic / processes have been encoded into Stored Procedures and sometimes Trigge

In the 90s and early 00s I worked on applications where the bulk of the business logic / processes have been encoded into Stored Procedures and sometimes Triggers. And it's easy in a lot of ways because you're working "close to the data". The issue it that SQL isn't the best language for encapsulating complicated and / or changing business logic. From a design perspective you end up creating "transaction scripts". This is great if what you are creating is simple and unlikely to change. As complexity increase and you received more and more Change Requests it becomes harder. Dino Esposito's book "Microsoft .NET: Architecting Applications for the Enterprise" covers this well and my experience reflects what he says. And while it's also easy to create "transaction scripts" in C#/Java, you can't take a Domain-Driven Design approach with T-SQL. I also agree with Brent's comment below, testing is far harder, although whatever project you're on automated testing has to be fully embraced or it's just overhead. (