A layered architecture is described as outdated. When is it still the right choice, and what is its real limitation?

When it is still right

For applications where the dominant structure is a request arriving, business rules applying, and data persisting — which is most enterprise applications.

It delivers real benefits cheaply:

• Comprehensibility. Any engineer knows roughly where to look for anything.
• A dependency rule that is easy to enforce — layers depend downward only — which is checkable statically and delivers most of what dependency inversion is for.
• Testability, with business logic isolated from transport and persistence.
• Low ceremony compared with more elaborate structures, when applied proportionately.

For a stable business application changing at a moderate rate, it is frequently the correct choice, and the reflex to dismiss it is fashion rather than analysis.

The real limitation

It organises by technical concern rather than by business capability, which produces two consequences.

1. A single feature touches every layer. Adding a field means changing the interface, the service, the repository and the schema. That is acceptable at moderate change rates and becomes the dominant cost when change is rapid — and it is worse when teams are organised by layer, because then every feature also requires every team.

2. The layers hide the domain. Reading the code tells you about controllers, services and repositories, and not about the business. In a domain with genuine complexity, the important structure is invisible.

The evolution that addresses it

Slice vertically first, layer within the slice. Modules organised by business capability — ordering, pricing, inventory — each internally layered. This keeps the dependency discipline and makes a feature change local to one module.

It is also what makes a future decomposition possible: the vertical slices are candidate service boundaries, and their change history is the evidence for whether they are the right ones.

The failure to avoid in either shape

Anaemic layers. A service layer that only forwards to a repository, and a repository that only forwards to an ORM, means three files where one would do — with all the indirection of layering and none of the isolation, because there is no logic to isolate.

Apply the structure where there is something to protect, and let simple data management be simple.