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.

Presentation Layer

The presentation layer is the top level of the application -it’s the user interface. In a web-based application, it’s likely written in HTML and JavaScript. In a mobile world, it’s likely your Android or iOS Application. The main function of it is to translate tasks and results from the business layer into something that the user can understand and use.

Business Layer

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.

Persistence Layer

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

Scalability	Reusability
Improved Availability	Easier Maintenance
Allows parallel tasks	Potential Easier Deployment
Improved Testability	Greater Flexibility

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.

It almost always makes for easier development to have the persistence layer mostly be generated code using a tool like the Entity Framework, or Hibernate. Other ORMs (What is ORM? ) like Knex could be a good option if you are using a JavaScript-based stack.

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.