It's based on the (false) belief that 2 section of the code base accessing/updating the same data will be performing the same function so it should be in one place. This one place is the data access layer and as more exceptions to this belief more and more "business logic" seeps into the data access layer. Then your business layer is anemic because most of the "logic" is moved to the data access layer and it's just an unnecessary pass though from the application layer.
Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join.
Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost.
So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds.
And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.
That's for that. I was thinking maybe it was just different versions of things like ODBC, but that sounds far worse. The database is already supposed to be the "data abstraction layer", and should be perfectly capable of handling multiple requests from different places.
I suppose software that just passes around database handle(s) would be a work of barbarism to these people.
Inner platform effect is different but often teams will do both.
The inner platform effect is usually data driven in a "we'll just code this once and generate dynamic code" sort of way. The dream of the inner platform effect is often to automate the production of these 23 useless layers.
Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join.
Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost.
So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds.
And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.