Layered Architecture

What Is Layered Architecture?

A Layered Architecture, is the organization of the project structure into four main categories: presentation, application, domain, and infrastructure. Each of the layers contains objects related to the particular concern it represents.

  • The presentation layer contains all of the classes responsible for presenting the UI to the end-user or sending the response back to the client (in case we’re operating deep in the back-end).

  • The application layer contains all the logic that is required by the application to meet its functional requirements and, at the same time, is not a part of the domain rules. In most systems that I've worked with, the application layer consisted of services orchestrating the domain objects to fulfill a use case scenario.

  • The domain layer represents the underlying domain, mostly consisting of domain entities and, in some cases, services. Business rules, like invariants and algorithms, should all stay in this layer.

  • The infrastructure layer (also known as the persistence layer) contains all the classes responsible for doing the technical stuff, like persisting the data in the database, like DAOs, repositories, or whatever else you’re using.

The main idea behind Layered Architecture is a separation of concerns – we want to avoid mixing domain or database code with the UI stuff, etc. The actual idea of separating a project into layers suggests that this separation of concerns should be achieved by source code organization. This means that apart from some guidance to what concerns we should separate, the Layered Architecture tells us nothing else about the design and implementation of the project. Layered Architecture gives us nothing apart from a guideline on how to organize the source code.

There are two important rules for a classical Layered Architecture to be correctly implemented:

  1. All the dependencies go in one direction, from presentation to infrastructure. (Well, handling persistence and domain are a bit tricky because the infrastructure layer often saves domain objects directly, so it actually knows about the classes in the domain)

  2. No logic related to one layer’s concern should be placed in another layer. For instance, no domain logic or database queries should be done in the UI.

Benefits and Drawbacks of a Layered Architecture

Pros:

  • Simplicity – the concept is very easy to learn and visible in the project at first grasp.

  • Consistent across different projects – the layers and so the overall code organization is pretty much the same in every layered project.

  • Guaranteed separation of concerns – just the concerns that have a layer and to the point that you stick to the rules of Layered Architecture, but it’s very easy with the code organization it implies.

  • Browsability from a technical perspective – when you want to change something in some/all objects of a given kind, they’re very easy to find and they’re kept all together.

Cons:

  • No built-in scalability – when the project grows too much, you need to find a key to organizing it further by yourself. The principles of Layered Architecture won’t help you.

  • Hidden use cases – you can’t really say what a project is doing by simply looking at the code organization. You need to at least read the class names and, unfortunately, sometimes even the implementation.

  • Low cohesion – classes that contribute to common scenarios and business concepts are far from each other because the project is organized around separating technical concerns.

  • No dependency inversion – in a classical Layered Architecture, the dependencies are direct and, conceptually, changes from a low-level infrastructure layer can propagate to more important higher layers.

Last updated

Was this helpful?