Have you heard of Layers before? Well one of the most known software architecture is the Layered Architecture. Layering your application is one of the tools you can use to get rid of big balls of mud, or atleast make sure it doesen’t become one.
A big ball of mud is exactly that. An application without any layering or separation of concerns. Everything is intertwined and coupled to dead. You might have fat controllers and no single separated place for your persistence mechanics.
Any respectable software developer want’s to create code, and an architecture that is easy to read, and seperates code based on functionality. Thinking in layers can help you with this.
What is Layered Architecture?
Layered architecture is all about the organization of code for the separation of concerns. Each layer contains objects related to a particular concern.
In a Layered system each layer depends on the layers beneath it. A layer should have no knowledge about any layer above it.
In a strict layered way we can only access the one layer exactly under it. If we use a more flexible approach, then we can access all the layers beneath the current layer. From experience I recommend the more flexible way. Otherwise we will create to much overhead code that does not provide any value.
The more flexible Layered Architecture then means we can access our Repository from the Infrastructure layer in the Presentation Layer.
Why Layered Architecture?
Layered Architecture allows you to think in concerns. It provides the tools, and make’s you think more about creating cleaner and more decoupled code. When you work on a layer, you can forget about the layer above it. You only need to think about your current layer, and the ones under it. This frees up brain power.
Allowing you to think more about what you are actually working on now.
You can also easily use a layer with multiple different higher level layers. You could create an API Presentation or a Web Presentation completely separate from each other and using the same Application layer. This because you decoupled your application and domain code from the presentation.
Layering
You have already seen the layer image with the 4 layers. Now lets go over each quickly to understand what each does. Don’t worry, we will go deeper into these layers in the future.
Domain
The Domain or Business Logic Layer is the core of your system. All your business models and services are defined here. This layers hold the rules and logic of the business. It’s the most important layer of your system. Treat it with care!
Application
The application layer is what holds everything together. It coordinates the objects and services of your application. Its the interface between your business logic and presentation. Application services represents how the application is driven.
This layer is also responsible for coordinating your domain objects and domain services to interact with internal or external services. For example sending an email when an invoice is approved, should be orchestrated in this layer. The domain layer is not responsible for initiating communication with external services.
Presentation
The Presentation or UI layer are your views, templates, controllers and forms. This is the interface to the outside world. Here we provide the interface for the users. Everything a consumer of our system sees, is presentation. This can be a web page or a Restful API. All interactions with the systems should happen trough this layer.
Infrastructure
The infrastructure layer holds the most low level code. The interactions with a database or an outside service like emails or messaging queues (sending the actual queue or email). Anything in here should be easy to replace. Code here should never effect anything related to logic, or how your application behaves. All code here is in essence, ‘details’.
Lasagna Architecture
I love lasagna. The kind you can eat. But not the Lasagna Architecture. This is what you get when you have to many layers. It becomes a big pile of lasagna. The sauce will flow between the layers and it becomes a mess. It makes the core even more complex.
There is no reason to have more then 4 layers. You could create an extra layer for persistence, split your application and domain over multiple layers. But if there is no good reason for that. Keep it simple.
Conclusion
Its important to remember that Layered Architecture is all about the seperation of concerns. Encapsulating and decoupling the code. This can be done by grouping your code by their functional role within your application.
But we need to be aware that creating to much layers is bad. Thats why I suggest only using the 4 layers I mentioned here.
Even more important to mention. This top/down approach of creating layers is a bit outdated at the moment. But the 4 layers I mentioned here, is something we can take to other more modern architectures. The Layered Architecture is the simplest one, and also the best way to learn about architecture. We start from this, and build on it by adding more concepts to it.