What’s Wrong with Layers?

Chances are that you have developed a layered (web) application in the past. You might even be doing it in your current project right now.

Thinking in layers has been drilled into us in computer science classes, tutorials, and best practices. It has even been taught in books.1

Figure 2.1 – A conventional web application architecture consists of a web layer, a domain layer, and a persistence layer

Figure 2.1 shows a high-level view of the very common three-layer architecture. We have a web layer that receives requests and routes them to a service in the domain layer.2 The service does some business logic and calls components from the persistence layer to query for or modify the current state of our domain entities in the database.

You know what? Layers are a solid architecture pattern! If we get them right, we’re able to build domain logic that is independent of the web and persistence layers. We can switch out the web or persistence technologies without affecting our domain logic, if the need arises. We can also add new features without affecting existing features.

With a good layered architecture, we’re keeping our options open and are able to quickly adapt to changing requirements and external factors (such as our database vendor doubling their prices overnight). A good layered architecture is maintainable.

So, what’s wrong with layers?

In my experience, a layered architecture is very vulnerable to changes, which makes it hard to maintain. It allows bad dependencies to creep in and make the software increasingly harder to change over time. Layers don’t provide enough guardrails to keep the architecture on track. We need to rely too much on human discipline and diligence to keep it maintainable.

In the following sections, I’ll tell you why.