Welcome to the third installment of our software architecture series, where we explore the architectural styles that form the backbone of modern applications. In this chapter, we delve deep into the world of Layered Architecture, also known as the n-tier architecture.

The Foundation of Business Applications

Layered architecture is the de facto standard for most business applications. Its widespread adoption can be attributed to its alignment with traditional IT team structures, where teams are organized by technical domains, including presentation, backend development, database management, and more. This familiarity with layered architecture makes it a natural choice for many business application development efforts.

Components within the layered architecture are organized into horizontal layers, each performing a specific role within the application. While the number of layers may vary, most layered architectures consist of four standard layers: presentation, business, persistence, and database. In some cases, the business and persistence layers are combined into a single business layer, particularly when the persistence logic, like SQL, is embedded within the business layer components. Smaller applications may have only three layers, while larger and more complex business applications may contain five or more layers.

Separation of Concerns

Each layer in the layered architecture style has a specific role and responsibility within the application. For example, the presentation layer handles user interface and browser communication logic, while the business layer executes specific business rules associated with a request. This separation of concerns is one of the powerful features of layered architecture. Each layer deals only with logic relevant to its specific domain.

This component classification facilitates the development of effective roles and responsibility models within the architecture, making it easy to build, test, govern, and maintain applications using this style. Layers are usually manifested through a namespace, package structure, or directory structure, making it clear how different components are organized within the architecture.

Closed Layers and Layers of Isolation

In a layered architecture, layers can be either open or closed. Closed layers mean that as a request moves from one layer to another, it must go through the layer right below it to get to the next layer below. For example, a request from the presentation layer must first pass through the business layer before reaching the persistence and database layers.

The concept of layers of isolation is key here. It means that changes made in one layer of the architecture typically don’t impact or affect components in other layers. Changes are isolated to the components within that layer and, possibly, another associated layer. This isolation prevents excessive interdependencies between components, which can make an architecture brittle and hard to change.

Layers of isolation also mean that each layer is independent of the other layers, with little or no knowledge of the inner workings of the other layers. This independence is invaluable for large refactoring efforts, as changes in one layer can be made without affecting other layers.

Open and Closed Layers

While closed layers facilitate layers of isolation and help contain change within the architecture, there are times when it makes sense for certain layers to be open. For example, introducing a shared services layer for common service functionality can be beneficial. This layer restricts access to the shared services to the business layer, preventing the presentation layer from accessing these services. In cases like this, open layers within the architecture can be beneficial.

Understanding the concept of open and closed layers is crucial for defining the relationship between architectural layers and request flows. Failure to document or properly communicate which layers are open and closed usually results in tightly coupled and brittle architectures that are challenging to test, maintain, and deploy.

Considerations and Analysis

The layered architecture is a well-understood and general-purpose style, making it a good starting point for most applications, particularly when you’re unsure which architecture style best suits your application. However, some considerations and analyses are necessary when implementing a layered architecture.

One concern is the architecture sinkhole anti-pattern, where requests flow through multiple layers with little or no logic performed within each layer. While some scenarios in every layered architecture may fall into this anti-pattern, the key is to analyze the percentage of requests that fall into this category. The 80–20 rule is often used to determine whether you’re experiencing the architecture sinkhole anti-pattern. If a majority of requests are simple pass-through processing, it might be worth considering open layers to control change.

Budget and time constraints can also influence your decision to adopt a layered architecture. This style is generally considered a monolithic architecture and is less complex than distributed architectures in terms of remote access, contract management, and fallacies of distributed computing. Additionally, most developers and architects are familiar with it, making it easier to understand and implement. If your changes are isolated to specific layers within the application, such as business rules or user interface changes, a layered architecture is a suitable choice.

However, you should avoid layered architecture if your application has high operational concerns like scalability, elasticity, fault tolerance, and performance. Layered architectures are not naturally scalable, as the entire application functionality must scale, which can be expensive and inefficient. They are also not very fault-tolerant, as a fatal crash in one part of the application can bring down the entire functionality.

Architecture Characteristics

Here’s a summary of the overall capabilities of the layered architecture in terms of architecture characteristics:

• Agility: ⭐⭐⭐⭐

• Simplicity: ⭐⭐⭐

• Scalability: ⭐

• Fault Tolerance: ⭐⭐

• Performance: ⭐⭐⭐

• Extensibility: ⭐⭐⭐

The layered architecture is well-suited for performance but has limitations in terms of scalability, elasticity, and fault tolerance.

---

In this article, we’ve explored the layered architecture style and its benefits, along with considerations and analyses for its implementation. Layered architecture remains a solid choice for many business applications, offering familiarity and ease of development. Stay tuned for Part 4, where we’ll continue to uncover the secrets of software architecture.