Layered Thinking and Modeling in Architecture Design: From Cloud Three‑Tier to SOA Integration

Today we discuss layered thinking and layered models in architecture design and the logic of architecture diagrams based on layered thinking.

Overview of Architecture Thinking

Architecture thinking is a collection of system thinking, structured thinking, programming thinking and other mindsets. Because architecture bridges the business reality and abstract IT implementation, its core is to understand that business drives technology and technology ultimately serves business, balancing many aspects such as requirements vs implementation, software vs hardware, static vs dynamic, cost vs benefit.

Previous articles have pointed out two focuses in architecture design: decomposition and integration.

Decomposition is fundamental; architecture must break complex problems into smaller parts that remain highly cohesive and loosely coupled, and then integrate them into a complete whole. The core of decomposition is defining the problem, which requires a clear understanding of requirements.

Integration is the complementary action: after decomposition, each component or subsystem is combined through appropriate interface design to form a complete system. Decomposition accelerates development and reduces complexity, but without integration it is meaningless.

Decomposition + integration can be understood as the core thinking and method of architecture.

After decomposition, a large system is split into many small modules, or a small module is further divided into steps. These scattered nodes must be aggregated and summarized to form a complete architecture.

The key to forming this architecture is layered thinking. Architecture layering is unavoidable and helps fully understand business systems or functional implementations.

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

When planning a large‑scale architecture, the standard cloud three‑layer model— IaaS, PaaS, SaaS—is often referenced. IaaS focuses on IT infrastructure and virtualization; PaaS on platform service capabilities; SaaS on concrete applications.

Resource layer evolves from physical resources to virtual logical resources, from virtual machines to lightweight containers. The platform layer, originally just a technical platform, now also includes a business platform, often referred to as the middle‑platform.

A service layer is added between platform and application to decouple resources from services.

If the application involves IoT, a network layer and a perception layer are usually added at the bottom, as shown in the smart‑city platform diagram.

In the platform + application construction mode, a separate service layer is often placed between platform and application to expose interface services. Resource + service + application is the common SOA layering pattern, so the service layer can be split out as its own layer.

Question 1: Database and Data Layer

In a complete overall architecture there is actually no "data layer"; the data layer only appears when expressing the layering of a single application system.

Listing structured and unstructured data as a separate layer in the overall diagram is incorrect; it belongs to the technical architecture.

Alternatively, a dedicated data layer can list common foundational data (e.g., in a smart‑city diagram). If these foundational data provide shared capabilities, they can be placed in the PaaS layer as a data‑platform domain.

Question 2: Service Layer and Services

When building the overall architecture, a capability‑opening platform or service layer can be added, but specific business service capabilities need not be shown, as they belong to the application layer (which is further split into business middle‑platform and front‑end applications).

Another reference diagram illustrates this:

This diagram is neither a pure cloud three‑layer nor a pure application three‑layer; it shows a support layer that resembles the current business middle‑platform and capability provision.

The overall architecture can be expressed as Technical Platform + Middle Platform + Application .

SOA Layering: Component‑Service‑Process

In SOA architecture layering, the focus is on services. Components belong to the logical resource layer, while services are the abstracted capabilities exposed externally.

SOA layering emphasizes an independent service layer—not a service bus—by explicitly drawing the business and technical service capabilities. When developing with SOA, the overall system is split into 4 components, 10 service domains, and 5 processes, which should be reflected in the diagram.

Reference SOA diagram:

The data layer is better replaced by a standard component layer to align with the SOA model. In the diagram the service layer already shows independent API service interfaces. Large data services are grouped into service domains such as user‑center or procurement.

Combining cloud and SOA results in a fused layering model where the service layer can be understood as a blend of component‑resource and service‑interface layers. A clearer diagram splits it into standard middle‑platform resource layer → service layer → application layer.

Cloud and SOA Architecture Fusion

Cloud layering emphasizes infrastructure, platform, and application; SOA emphasizes resource, service, and application; traditional three‑tier includes IT infrastructure, technical platform, database, middleware, and application. These various methods help further fuse layered architecture patterns.

Architecture layering methods include infrastructure, platform, component, support, service, application, data, presentation, etc., which can cause ambiguity.

We discuss both technical architecture (using the cloud three‑layer model) and application architecture (using the eTOM resource‑service‑application model). The fusion of the two yields a complete cloud‑SOA layered architecture.

Each cloud layer can itself be split into resource, service, and application. For example, the IaaS layer provides physical/virtual resources (resource layer), exposes APIs as services (service layer), and builds a public‑cloud operating platform (application layer). In the SaaS layer, business components are resources, abstract APIs are services, and the front‑end business or process is the application.

Application Architecture Layering

Classic three‑tier architecture consists of User Interface Layer, Business Logic Layer, and Data Access Layer.

Additional layers such as Facade, API service, or DTO may be added, but they do not change the overall three‑tier logic.

The three tiers map to data access (handling persistence), business logic (processing rules), and presentation (front‑end interaction).

Domain‑driven design adds an Application layer between UI and Business Logic, renames Business Logic to Domain layer, and renames Data Access to Infrastructure layer, expanding the scope beyond a specific DBMS.

In domain modeling, the domain layer provides domain objects and services, while the business logic is the capability exposed by those domain objects.

Independent application layer split:

The domain layer offers domain models and services; the application layer assembles multiple domain services and exposes them to the front‑end.

The application layer represents common capabilities across different front‑ends (e.g., web, mobile). A single business function such as order placement should be implemented once in the application layer and reused by both BS and APP front‑ends.

In microservice and middle‑platform architectures, the application layer is essential for aggregating shared service composition and orchestration logic, which should not belong to any individual front‑end.

UI Layer or Interface Layer

When developing a middle‑platform microservice module without a UI, the topmost layer is simply an API interface service layer, which can be consumed by both APP and BS front‑ends.

Software Technical Architecture Layering

Technical architecture diagrams can still follow the classic three‑tier model, focusing on key technology components or services used in each layer.

If the system itself is a technology platform (e.g., a big‑data platform), the overall diagram should first be layered, then each layer detailed with its specific technologies.

For a big‑data platform, layers might include data collection, storage, processing, analysis, and application, each with its own key technologies.

The technical stack diagram can also follow the technical architecture pattern.

Technical architecture should answer which key technologies, open‑source products, or tools are used (e.g., RabbitMQ for messaging). It can detail specific products or just product categories.

Technical architecture and functional architecture share the concept of layering, but the former focuses on technology components while the latter focuses on business functions.

Single Application Function Architecture

Function architecture describes what capabilities an application provides, not how they are implemented with three‑tier technical layers.

Business can be layered into support layer, execution layer, and decision‑management layer, forming a basic functional layering model.

Even a single application may not have cloud or PaaS concepts, but it usually has a common technical support layer, an application layer, and a portal layer for construction.

Logic of Layered Architecture Diagrams

When drawing overall architecture diagrams, avoid mixing different scenario diagram styles to prevent confusion.

Use cloud three‑layer and SOA three‑layer patterns for the overall view, and differentiate between technical architecture diagrams and functional architecture diagrams for specific application systems.

Diagram logic: the left and right sides usually contain standards, regulations, security management, quality management, technical standards, and dev‑ops guidelines; the middle is the core layered construction.

The core layers are resource, platform, application, and portal. The application layer can be further split by business domain or lifecycle stages.

The service layer sits between resource/platform and application, unified via SOA platform or API gateway, forming a complete resource + service + application loosely‑coupled architecture.

Multiple views of the architecture can be presented for different audiences: functional diagrams for business users, technical diagrams for developers, and operational diagrams for ops engineers.