Layered Thinking and Layered Models in Architecture Design

Architecture thinking is a collection of systematic, structural, and programming mindsets that bridge business reality and IT implementation. The core principle is that business drives technology and technology serves business, requiring a balance among requirements, implementation, software, hardware, static and dynamic aspects, cost and benefit.

Two key actions in architecture are decomposition and integration. Decomposition breaks complex problems into cohesive, loosely coupled modules, while integration connects these modules through well‑designed interfaces to form a complete system.

Layered thinking is essential for constructing a clear architecture. By applying layers, one can better understand the overall system or specific functionality.

Cloud Platform Three‑Layer Architecture: Resource‑Platform‑Application

The standard cloud model consists of IaaS (infrastructure), PaaS (platform services), and SaaS (applications). The resource layer includes physical, virtual, and container resources; the platform layer may be split into technical and business platforms; a service layer between platform and application decouples resources from services.

For IoT scenarios, additional network and perception layers may be added, as shown in the smart‑city example.

Question 1: Database and Data Layer

In a full‑scale architecture, a dedicated data layer is not a separate concern; it appears only in the context of a single application’s layered design. In a total architecture diagram, databases and data stores are represented within the technical architecture rather than as a distinct layer.

Question 2: Service Layer and Services

A service layer can be introduced to expose capabilities without detailing each business service, aligning with a middle‑platform approach that bridges resources and applications.

SOA Layering: Component‑Service‑Process

SOA emphasizes a distinct service layer, where components belong to the logical resource layer and services expose capabilities externally. A typical SOA diagram shows components, service domains, and processes.

The service layer can be merged with the component layer to form a unified middle‑platform in a cloud‑SOA hybrid model.

Cloud and SOA Architecture Fusion

Cloud three‑layer architecture focuses on infrastructure, platform, and application, while SOA focuses on resource, service, and application. Combining them yields a comprehensive model where each cloud layer can be further split into resource, service, and application sub‑layers.

Application Architecture Layers

The classic three‑tier model consists of User Interface, Business Logic (Domain), and Data Access (Infrastructure) layers. Additional layers such as Facade, API, or DTO may be introduced without changing the core hierarchy.

Domain‑Driven Design adds an Application layer between UI and Domain, renames Business Logic to Domain, and Infrastructure replaces the traditional Data Access layer.

Interface vs. Presentation Layer

Microservice modules without a UI expose only API interfaces, which can be consumed by both mobile apps and web front‑ends.

Software Technical Architecture Layering

Technical architecture mirrors the three‑tier model, focusing on key technologies and tools used at each layer (e.g., messaging middleware like RabbitMQ, data storage, processing frameworks).

Single‑Application Function Architecture

Function architecture describes the capabilities of an application without detailing the underlying three‑tier implementation. It can be divided into support, execution, and decision‑management layers.

Diagram Layering Logic

When drawing an overall architecture diagram, reference cloud three‑layer and SOA three‑layer models, keeping the core layers (resource, platform, application) distinct and adding a service layer between platform and application.

Different stakeholders (business users, developers, operations) require different views of the architecture, so mixing diagram styles should be avoided to prevent confusion.