Definition and Fundamental Concepts of Layered Architecture

Key Insight

The layered architecture, also known as the n-tiered architecture style, is a prevalent and often default choice for applications due to its inherent simplicity, familiarity among developers, and low implementation cost. Its natural fit with organizational structures, as described by Conway's law—where teams for user interface (UI), backend, rules, and databases mirror architectural tiers—further contributes to its widespread adoption in business applications. This style is frequently implemented even when no explicit architectural decision has been made, often resulting from teams 'just starting coding,' leading to anti-patterns such as 'architecture by implication' or 'accidental architecture'.

Components within this architecture are logically organized into horizontal layers, each assigned a specific functional role like presentation logic or business logic. While adaptable in terms of layer count, most layered architectures feature four standard layers: presentation, business, persistence, and database. For smaller applications, the business and persistence layers might merge into a single business layer, resulting in three layers, whereas more complex applications can utilize five or more layers. Deployment configurations vary, with one common variant combining presentation, business, and persistence into a single deployment unit while the database remains external; another separates the presentation layer into its own unit, combining business and persistence, also with an external database; a third variant integrates all four standard layers, including an embedded or in-memory database, into a single deployment, particularly useful for smaller applications and on-premises products.

A key principle of layered architecture is 'separation of concerns,' where each layer possesses distinct responsibilities; for instance, the presentation layer manages UI and browser communication, while the business layer executes specific business rules. This creates an abstraction: the presentation layer only needs to display customer data without understanding its retrieval mechanism, and the business layer processes data from the persistence layer without concern for display formatting or data origin. Although this technical partitioning by role (e.g., presentation logic, business logic) enables developers to leverage specialized expertise, it leads to a lack of overall agility. Business domains, such as 'customer,' become fragmented across multiple layers (presentation, business, rules, services, database), complicating changes to that domain and making the style less suitable for a domain-driven design approach.