Mastering Layered Architecture: From Cloud Stacks to SOA Integration

Architectural Thinking Overview

Architectural thinking integrates system, structured, and programming mindsets to create a bridge between business reality and IT implementation. The core principle is business‑driven technology: technology exists to serve business goals, and architecture must balance requirements, implementation constraints, software/hardware choices, static and dynamic aspects, as well as cost‑benefit considerations.

Decomposition and Integration

Two fundamental actions in architecture are decomposition and integration . Decomposition breaks a complex problem into cohesive, loosely‑coupled modules after a clear understanding of requirements. Integration then assembles those modules through well‑designed interfaces, ensuring the whole system functions as a unified entity.

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

The standard cloud three‑layer architecture consists of:

IaaS (Infrastructure as a Service) : physical resources, virtual machines, containers, and other compute/storage infrastructure.

PaaS (Platform as a Service) : platform‑level services, often split into a technical platform and a business (mid‑) platform.

SaaS (Software as a Service) : end‑user applications.

A dedicated service layer between platform and application decouples resources from services, enabling flexible API exposure.

For IoT or smart‑city scenarios, additional network and perception layers are added beneath the resource layer.

SOA Layering: Component‑Service‑Process

In Service‑Oriented Architecture (SOA), the logical resource layer contains components, while the service layer exposes capabilities as APIs. A typical SOA diagram includes four component groups, ten service domains, and five process types.

The service layer can be further split into a data‑platform domain within the PaaS layer when common data services are required.

Fusion of Cloud and SOA Layers

Both cloud and SOA share a three‑layer structure (resource, service, application). In practice each cloud layer can be refined into sub‑layers:

Resource sub‑layer : physical or virtual assets.

Service sub‑layer : APIs that expose the underlying resources.

Application sub‑layer : end‑user services built on top of the exposed APIs.

Example: the IaaS layer provides virtual machines (resource), exposes provisioning APIs (service), and together forms a public‑cloud service platform (application). Similarly, SaaS components map to resources, APIs, and front‑end functionality.

Application Architecture Layers

The classic three‑tier model consists of:

User Interface (UI) Layer

Business Logic (Domain) Layer

Data Access (Infrastructure) Layer

Additional optional layers such as Facade, API Gateway, or DTO can be introduced without breaking the core structure.

Domain‑Driven Design (DDD) adds an Application Layer between UI and Domain layers and renames the Data Access layer to Infrastructure Layer , broadening its scope beyond a specific DBMS.

Domain vs. Business Logic (DDD Perspective)

In DDD the domain model represents business concepts rather than raw tables. Services aggregate DAO capabilities according to domain concepts, and the domain layer exposes business rules as part of the domain model.

Independent Application Layer Splitting

The Application Layer orchestrates multiple domain services and presents a unified API to front‑end clients (mobile, web, etc.). This avoids duplicated logic across different client types. For example, an e‑commerce order process is implemented once in the Application Layer and consumed by both a web portal and a mobile app.

Software Technical Architecture Layering

Technical architecture also follows a three‑tier model, focusing on key technology components per layer. Typical layers for a big‑data platform include:

Data Ingestion

Data Storage

Data Processing

Data Analysis

Application Services

Each layer is populated with concrete technologies (e.g., Kafka for ingestion, HDFS for storage, Spark for processing, Tableau for analysis).

Guidelines for Drawing Architecture Diagrams

When creating a comprehensive diagram:

Place core layered architecture (resource‑service‑application) at the center.

Separate standards, security, quality, and operational specifications on the left and right margins.

Avoid mixing different layering models (e.g., cloud IaaS vs. application three‑tier) in a single view to prevent confusion.