It is not a secret that investing in a good software architecture design will save you time, money and headaches during the whole Software Development Life Cycle. That’s why choosing the software architecture pattern that best fits to your needs it’s crucial.
There aren’t any patterns or approaches that will work perfectly for every application you may want to build, but some of them are certainly worth to know and implement in order to develop and maintain a high quality software.
One of the most common architecture pattern is the Layered Architecture (or N-tier architecture pattern).
Overview
The Layered Architecture pattern splits your application into layers, each of them with a specific role and responsibility within the solution, providing at the same time abstraction and separation of concerns.
Usually, you will have the following layers:
⦁ Presentation Layer – is mainly used for getting user data and then passing it further to Business Layer to be processed.
⦁ Business Layer – process the data according to all the business logic of an application.
⦁ Persistence Layer – deals with storing and retrieving (persisting) data from a data store (for example: a database).
⦁ The database layer – stores all the application data.
Depending on the size and complexity of your application you may have from 3 to 5 or more layers.
Pros
⦁ Separation of concerns – ensure single responsibility(concern) of each individual component.
⦁ Easy to develop – because it’s so well known and is not the most complex pattern to implement. It’s also a good starting point for most applications, especially when you are not sure what architecture pattern to implement in your project.
⦁ Easy to test – because every layer can be covered with unit tests separately and components belonging to specific layers can be mocked or stubbed.
⦁ Isolation – each layer is independent of the other layers, having little or no knowledge of the inner workings of each other, that’s why changes made in one layer usually don’t impact or affect the others
⦁ Easy to maintain (for small and medium sized projects) because it has well-defined interfaces and limited component scope.
Cons
⦁ Deployment can become an issue, particularly for larger applications. A change to a particular layer means the whole system must be redeployed.
⦁ It’s expensive to scale once your application complexity grows and more features should be added into the project.
⦁ Can cause Performance issues (especially in big applications) when adding new layers.
When to use it?
As I mentioned above, the Layered Architecture is a good starting point for most applications, small and medium sized projects, especially for startups or proof of concepts.
For example Uber, started with a Layered Architecture and once they grew in popularity the old architecture just couldn’t keep up, and they have completely rewritten and redesigned it using Microservices.
But of course not all applications end up being a great success, and if you will start implementing a more complex architecture pattern, you spend more time and waste more money on something you are not even sure it will worth the effort.
For example, you may have a small application with almost no logic within one layer, then maybe you don’t need at all that layer. Or you may have the opposite, a complex logic within one layer that can be separated in multiple layers or split into different services in order to be easier to maintain.
That’s why you don’t have to use a specific pattern just because is very popular or it may be useful somehow in the future. Use it only if you need it, and will really solve your problems or will prevent an issue you can clearly anticipate it will happen.
Published by