Layered architecture is a Monolithic architecture style, with a well-defined responsibility. And each of these players will have some relationship of modularity and components within them, but all along with the same category of the layer. For example business layer for business logic, persistence layer for managing things like object-relational mapping, data layer for handling database, etc.
This is a way more organized way to lay down your classes and one of the biggest advantages of a layered architecture is you make each of this closed, what that means requests that come into this architecture must go through every layer. That means from the top till the bottom where the database layer resides usually. That means for the persistence layer it has to go through the business layer that what closed means. It will only accept requests from the immediate layer above it.
The purpose of this architecture is twofold, the primary one is getting all the like things together, so separation of concern is the key motivator here. And the second one is the layers of isolation because these layers are typically isolated from one another and can only communicate to well-defined interfaces so if you decide to swap out your databases from Oracle to MySQL, this kind of architecture next it a little bit easy. This will have some impact on the persistence layer and a huge impact on the business layer but those changes should not expand above the layers of isolation that you have established.
There are also many hybrids and variance in architecture patterns general for a layered architecture specifically. But then a common little anti-pattern pops up in a lot of systems. Request standpoint layered architecture is a step machine, you are sending a request through every state to do something to it. But what happens if you have a service layer and some of the requests need to skip the services layer. So then the optional layer, we have to make it optional so we have to make it an open layer. By creating an open layer in layered architecture what you are doing is, if there is value in the service layer I should go through it, but if not I can bypass it and move to the next layer. This solves the architecture’s sinkhole pattern but it also creates a trade-off. Because now if I want to change the persistent layer, is it easier that I have an open layer just above me, which is more difficult. Turns out it is more difficult because now I want to swap out the persistence layer I have to worry about Breaking both of the services and the business layer because they are both couples to the persistence layer. So part of the logic of having close layers here is we reduce the amount of coupling between layers meaning you improve the isolation characteristic of every layer. So more you open the layers of your architecture you are throwing away the benefits or you are not using the benefits of this layered architecture for you. And that is something you need to pay very close attention to as an architect.
There is a saying, “death by a thousand little tiny cuts”. So here is a scenario where you have built a layered architecture perfect solving every problem. But now people will come to you and say we want to use architecture. Sophos a group of developers will come to you and say we want to build reports in the presentation layer and it is too slow for us to go to every layer (the presentation layer is the first one and the last one is the database layer in between there are business layer persistence etc), permit us to go to directly to the database layer now here is the question as an architect should you are now this?? This is a question of pattern governance. New design an architectural pattern, there is a reason for building that specific pattern, once you allow this to happen in the above case the whole thing crumbles down. So now you don’t have a clean separation between layers, and what is happening here is your database schema being fossilized in the presentation layer. So when you cannot make changes in the other end of the architecture that pain you cannot meet any changes in between, it is too risky. So this is a very bad situation, we need to find a better solution for this problem because at the end of the day if this continues it is not so far when you will have a spaghetti system and spaghetti architecture.
Let’s check the scoreboard, agility zero, deployments zero, performance zero, scalability zero. The plus point is testability is ok, simplicity is ok, and the cost is ok.