A Layered Architecture is an application that has been designed to have multiple separate tiers or layers that can be located on different physical machines and are logically separate. You may also hear of a Layered Architecture being referenced as a n-Tier Architecture because it could have any number of tiers.
The Layered architecture is a well-proven software architecture – it’s being used in many large enterprise-level applications and allows us to provide a very scalable system. Companies like Salesforce, NetSuite, Oracle, Microsoft, and many others are using it for many large systems.
It’s really common, likely the most common, to see a three-tier application that has separate layers for the Presentation Layer, Business Layer, and some sort of persistence or Database Layer. A three-tier application would have a diagram that looks something like this:
Having separate layers or tiers allows developers to create highly reusable applications with maximum flexibility. It’s possible to have many different applications potentially talking to some of the same business layer or persistence layers.
Let’s take a look at the different layers and see how they could potentially be interacting.
The business layer is responsible for making logical decisions – it’s where our domain logic resides. It’s where the business keeps its rules and does its calculations.
It also is responsible for moving data between the presentation and persistence layers.
The persistence layer is responsible for storing data and files. It gets the data from the database or the hard drive and sends it back to the business layer which then sends it back to the presentation layer.
In a well-designed system, when we make changes to the database structure, database access objects, stored procedures, or anything else – changes shouldn’t need to happen at the business layer.
If you are using caching or database scaling it is deciding which database to use.
How Many Layers Are too Many?
There’s no set number of layers. I like to stay in the three to four range for layers as I find it starts to get too difficult to decide where to stick something.
I like to separate out the Data Access Layer and have it manage which database to potentially ask for access or maybe whether to cache it or not.
Advantages of the Layered Architecture
|Allows parallel tasks
|Potential Easier Deployment
Disadvantages of Layered Architecture
|Development can take longer
|The impact of a change can be harder to predict
|Smaller applications can be made more complex
Best Practices for Layered Architecture Development
Decouple layers from other layers using things like REST or SOAP. It rarely makes sense for one layer to skip another layer to do something. For example, the presentation layer should never skip over the business layer to talk directly to the persistence layer.
Caching layers can be a great way to speed up the performance and avoid potentially having to add additional compute resources to a particular layer.
In the client presentation layer, common code should be added to separate libraries to encourage code reusability for all types of clients.
Wrapping It Up
The layered architecture allows us to control and encapsulate the complexity of large applications. For smaller applications though it can add significant complexity. When deciding on a software architecture it’s usually wisest to use the simplest solution that allows you great flexibility to make decisions later.
The layered architecture is a well battle-tested technique, and I highly recommend you consider it for anything that you are building now or in the future.