Layered #

Layered architecture is suitable for applications that can be organized into a hierarchy of layers, where each layer provides services to the layer above and uses services from the layer below.

Topology #

Example component diagram:

• Component: Layers
  • each layer groups components at similar abstraction level (e.g., UI, domain/business, data/infrastructure).
  • a layer usually only depends on layers below it.
• Connector: method calls (or RPC) across layer boundaries, typically behind interfaces.
• Configuration: a common constraint is that communication happens only between adjacent layers.

Pros and cons #

• Pros
  • Maintainability: it is often possible to swap implementations within a layer (e.g., replace storage) if contracts are kept; changes in one layer affects at most two adjacent layers.
  • Readability: each layer has a consistent abstraction level, making the system easier to understand.
• Cons
  • Efficiency: abstractions in high-level functions can add overhead; performance requirements may force the coupling of high-level functions to their low-level implementations (breaking the encapsulation of the layers).
  • Not all systems map cleanly to layered structures.

Variants #

Allowing non-adjacent layer communication (layer bypass) #

This variant relaxes the adjacent-layer constraint: a higher layer may call a lower layer directly (e.g., UI calling the data layer) to reduce overhead or boilerplate. It can improve efficiency and development speed for simple flows, but it tends to erode boundaries over time and makes testing/refactoring harder.

Real-world examples #

Computer network layers #

The Internet protocol stack is a canonical layered architecture: application protocols build on transport protocols (e.g., TCP/UDP), which build on network-layer routing (IP), which in turn build on link-layer delivery (Ethernet/Wi‑Fi, etc.). In this mapping, each protocol layer is a “component group” with a clear abstraction boundary, and the connectors are the service interfaces and data units passed between layers (e.g., an application payload becomes a transport segment, then an IP packet, then a link-layer frame). In practice, real systems sometimes introduce cross-layer interactions (e.g., performance optimizations), which is a good illustration of the trade-offs behind the layer-bypass variant.

Further reading: CS 456/656: Computer Networks

Android app architecture #

Android’s recommended app architecture is often explained as a layered structure with explicit boundaries between UI, domain/business logic, and data/infrastructure. The layers are “components”, and the connectors are (mostly) dependency-directional calls through interfaces (often with reactive streams carrying data upward). It is also a good example of how real projects sometimes allow a controlled bypass for performance or convenience—and why teams often enforce boundaries with interfaces, tests, and dependency rules.

Further reading: Android: Guide to app architecture

Eclipse IDE #

Eclipse is described as a platform with layered responsibilities: lower-level platform/runtime services enable UI frameworks and higher-level tools. From a topology perspective, the layers define what kinds of components exist at each level, and plugin APIs (and extension mechanisms) act as the main connectors across those layers. Eclipse also illustrates that large systems often blend styles (e.g., layering plus implicit invocation through extension points/events).

Further reading: The Architecture of Open Source Applications: Eclipse