Advantages, Disadvantages, and Principles of Layered Architecture in Software Systems

In Internet technology a "silver bullet" is often described as adding an extra layer to solve various problems. When designing micro‑service architectures, data‑warehouse schemas, protocol stacks, or many design patterns, we frequently encounter layering. This article explores the commonalities, benefits, drawbacks, and guiding principles of layering.

Advantages of layering are summarized as five points: abstract stability, functional reuse, functional cohesion, hiding complexity and change, and scaling the system. Although the first four can be loosely grouped under "abstraction", each has a distinct focus.

The author recalls the first encounter with layering during a promotion presentation, showing an early QQ Space WNS access framework. The discussion highlighted why a dispatch layer was introduced: to perform routing, disaster‑recovery configuration, and to shield upstream acc from changes. This illustrates the advantage of hiding complexity and change.

Other advantages demonstrated include:

Reuse : the dispatch layer encapsulates decompression, authentication, encryption, and chunk assembly, providing common capabilities.

Cohesion : separating concerns keeps the long‑connection acc layer stable while the dispatch layer can be restarted independently for routing updates.

These benefits are common in anti‑corruption layers, adapter layers, and other architectural patterns.

Disadvantages of layering are grouped into three categories: increased system complexity, performance/storage overhead, and added dependencies.

System complexity : premature or unnecessary layers can make a simple two‑step workflow overly complicated.

Performance/Storage consumption : in high‑traffic scenarios, an extra forwarding layer can consume significant resources, making a flatter design preferable.

Dependency addition : each new third‑party component introduces risk; multiple layers multiply failure probabilities (e.g., 99.99% × 99.99% ≈ 99.98%).

Principles for layering are proposed to balance the trade‑offs:

Some layers must be retained for global consistency (e.g., DWD and DIM in a data‑warehouse).

Cross‑layer calls are allowed; reverse calls are prohibited.

Prefer dependencies on lower layers; avoid same‑layer dependencies to prevent circularity.

Lower layers should be the most stable.

A layer may contain multiple sub‑layers, but each should have a clear purpose.

Examples of these principles include the classic data‑warehouse layering (DWD → DWM → DM → APP) and DDD‑based micro‑service layering, where the domain layer remains autonomous and thin application layers orchestrate use cases.

In summary, the article reiterates the five advantages, three disadvantages, and the guiding principles, emphasizing that a well‑designed layered architecture can improve stability and scalability while avoiding over‑design.