Layered Architecture Design: From Decomposition to Cloud and SOA Integration

Architecture thinking is a collection of systematic, structural, and programming mindsets that bridge business reality with IT implementation, emphasizing that technology must serve business needs and balance multiple concerns such as cost, performance, and scalability.

Two core activities in architecture design are decomposition—splitting complex problems into cohesive, loosely‑coupled modules after clearly understanding requirements—and integration—combining those modules through well‑designed interfaces to form a complete system.

Applying layered thinking, the article introduces the cloud platform three‑layer model (IaaS, PaaS, SaaS) and explains how each layer can be further broken down into resource, service, and application sub‑layers, with additional network and perception layers for IoT scenarios.

It discusses common questions about the data layer, arguing that a separate data layer only makes sense in application‑level diagrams, while in a total architecture it belongs to the technical architecture; a shared data platform can be placed in the PaaS layer.

The service layer is treated as an ability‑exposure platform, not a detailed list of business services, and can be represented as a separate capability‑opening layer.

SOA layering (component‑service‑process) is presented, highlighting the need for an independent service layer that exposes APIs, and showing how component, service domain, and process layers map onto cloud layers.

The article then merges cloud and SOA models, describing a unified resource‑service‑application hierarchy where each cloud tier (IaaS, PaaS, SaaS) can be further split into these three sub‑layers.

Application architecture layering is revisited, covering the classic three‑tier model (UI, business logic, data access) and its extensions such as facade, API, and DTO layers, as well as domain‑driven design that introduces an application layer between UI and domain.

Software technical architecture follows the same layered principle, focusing on key technology components (e.g., messaging middleware, big‑data platforms) without tying them to specific business functions.

For single‑application functional architecture, the article suggests a business‑support, execution, and decision‑management layering, and shows how to map these onto resource, platform, and application layers.

Finally, it provides practical diagramming guidance: keep cloud and SOA three‑layer patterns separate from functional diagrams, avoid mixing different layering logics, and use a clear left‑right‑center layout to distinguish standards, core layered architecture, and service integration.