Mastering Layered Architecture: From Cloud Stacks to SOA Models

Architecture Thinking Overview

Architecture thinking combines system, structured, and programming mindsets to bridge real‑world business and abstract IT implementations. Its core principle is that business drives technology, and technology ultimately serves business goals, balancing requirements, implementation, cost, and benefit.

Decomposition and Integration

Decomposition breaks complex problems into high‑cohesion, loosely‑coupled modules, requiring a clear understanding of requirements. Integration then connects these modules through well‑designed interfaces, ensuring the pieces form a complete whole.

Why Layered Thinking Matters

Layered architecture clarifies the structure of a system, making it easier to understand business functions and technical implementations.

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

The standard cloud stack consists of IaaS (infrastructure), PaaS (platform services), and SaaS (specific applications). The resource layer evolves from physical hardware to virtual machines and containers; the platform layer now often includes a business‑oriented “mid‑platform” or “middle‑platform”. A service layer is added between platform and application to decouple resources from services.

IoT applications may further introduce a network layer and a perception layer beneath the resource layer.

Database and Data Layer

In a complete enterprise architecture, a dedicated “data layer” does not exist; data concerns are expressed within the technical architecture. When a shared data platform is needed, it can be represented as a domain within the PaaS layer.

Service Layer and Services

A separate capability‑exposure platform can be defined without enumerating specific business services, which belong to the application layer.

SOA Layering: Component‑Service‑Process

SOA emphasizes an independent service layer that exposes business and technical capabilities. A typical SOA diagram shows components, service domains, and processes, with the service layer visualized as distinct API interfaces.

Fusion of Cloud and SOA Architecture

Both cloud and SOA share a three‑layer view: resource, service, and application. In IaaS, physical resources become APIs (service layer) that power public cloud platforms (application layer). In SaaS, business components are resources, APIs are services, and the front‑end is the application.

Application Architecture Layering

The classic three‑tier model consists of UI layer, Business Logic (Domain) layer, and Data Access (Infrastructure) layer. Additional layers such as Facade, API, or DTO may be introduced without breaking the overall structure.

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

Domain vs. Business Logic Layer

Domain models represent business objects; services expose domain capabilities. DAO implementations may be split, while Service logic aggregates domain operations.

Independent Application Layer Split

The Application layer composes multiple domain services and exposes them to front‑ends (web, mobile, etc.), avoiding duplication across platforms.

Interface vs. UI Layer

Microservice modules without UI expose only an API (interface) layer, which can be consumed by both mobile and web clients.

Software Technical Architecture Layering

Technical architecture also follows a three‑tier model, focusing on key technology components or services at each layer (e.g., messaging middleware like RabbitMQ, data processing frameworks, etc.).

Single‑Application Functional Architecture

Functional architecture can be divided into Support, Execution, and Decision‑Management layers, providing a clear view of business capabilities.

Architecture Diagram Layering Logic

When drawing an architecture diagram, avoid mixing different modeling styles. Use cloud three‑layer or SOA three‑layer patterns for the core, and add standards, security, and quality management on the sides.

Diagram Construction Logic

Separate the diagram into left/right sections for standards and the central part for layered architecture (resource, platform, application, portal). The service layer connects resource and application layers, forming a loosely‑coupled, resource‑service‑application stack.