Layered Architecture

Layered architecture is an approach to breaking down large applications into manageable areas. This improves maintainability of the software by isolating functionality, improving testability, allowing code to be reused, and changes to be made to a layer without impacting another in a significant way.

In this section


The terms tier and layer are often used interchangeably. This isn't wrong when the context is correct, but it is important to make and understand the distinction that they are not the same in software architecture. A tier refers to the physical location that your code base runs. A common case would be a client-server application that has two tiers, the physical client, and physical server. Tiers are distinguished by they fact that they are separated by physical boundaries.


Layers on the other hand, are logical separations of concerns in your application architecture. You might design your architecture to run a layer of the software on a specific tier, or share a layer across tiers. These decisions usually account for requirements such as security, performance, or management of the infrastructure. The most common and accepted layers of software are listed below. Each article will go into depth explaining the purpose of each layer, as well as provide best practices.

Data Layer

The data layer is also referred to as the DAL, or data abstraction layer. This particular area of the software is responsible for encapsulating all access to application data. Typically, application data will be stored in a database like SQL Server or MySQL, but the DAL can also encapsulate data stored in other formats, such as xml.

Learn more.

Business Layer

The business layer is also referred to as the BAL, or business abstraction layer. Sometimes it is also referred to as the domain layer. The BAL is responsible for encapsulating all business logic for a given problem domain.

Learn more.

Service Layer

An application architecture might contain one or more service layers. Typically, a service layer is used to abstract communication between a set of services. Services could be web services, third party api, or other subsystems of a product. It's primary goal is to provide a consistent mechanism for sending data, receiving data, and handling errors.

Learn more.

Application Layer

The application layer, or also called the presentation layer, is the layer of the software responsible for the user interface, and ultimately the specific environment hosting the software. In a web application, your app layer will be the web application and the web server, while in a desktop application, it would be the desktop client and the OS.

Learn more.

Choosing the right architecture

The right architecture largely depends on the application you will build, and ultimately how complex the requirements are. How many tiers will your architecture have? Is your application heavily data driven? Do you have complex domain requirements or business rules? These are the questions you need to ask yourself when laying out an architecture.

Not every application needs a full layered architecture. Small applications might not require a layered architecture at all. You might choose to write your data access and business logic directly in the presentation. The important part is you architect a solution that fits your needs. This should also include scaling the software. So how do you determine these needs? What precisely dictates the need for a DAL, BAL, and presentation layer? To best help you do this, you can utilize the table below.

  • 1 TIER DAL / BAL / SAL / APP

  • 1 TIER DAL / BAL / SAL / APP

  • 1 TIER DAL / BAL / SAL / APP