Mastering Architecture Thinking: From Cloud Layers to SOA Integration

Architecture Thinking Overview

Architecture thinking is a collection of system, structured, and programming mindsets that bridges the business world and abstract IT implementation; its core is to understand that business drives technology and technology ultimately serves business, requiring balanced trade‑offs among requirements, implementation, hardware/software, static/dynamic aspects, and cost/benefit.

Decomposition and Integration

Effective architecture first decomposes complex problems into high‑cohesion, low‑coupling modules, then integrates them through well‑designed interfaces to form a complete whole; without successful integration, decomposition loses its purpose.

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 emphasizes infrastructure and virtualization, PaaS builds platform services (including emerging business‑platform or middle‑office layers), and SaaS delivers concrete applications. An additional service layer between platform and application decouples resources from services. IoT scenarios may add a network layer and a perception layer beneath the resource layer.

SOA Layering: Component‑Service‑Process

SOA architecture emphasizes an independent service layer that abstracts capabilities; components belong to the logical resource layer, while services expose those resources. A typical SOA design splits the system into four components, ten service domains, and five processes, each illustrated in the accompanying diagram.

Fusion of Cloud and SOA Architectures

The combined model highlights that cloud layering focuses on infrastructure, platform, and application, while SOA focuses on resource, service, and application; traditional three‑tier application systems add middleware and database layers. Merging these perspectives yields a comprehensive layered architecture that can be expressed as resource‑service‑application across all three cloud layers.

Application Architecture Layering

The classic three‑tier model consists of User Interface, Business Logic, and Data Access layers, optionally extended with a Facade, API, or DTO layer. Domain‑Driven Design adds an Application layer between UI and domain (business) layer, renames Business Logic to Domain layer, and calls Data Access the Infrastructure layer.

Software Technical Architecture Layering

Technical architecture can reuse the three‑tier model, detailing key technologies per layer (e.g., messaging middleware like RabbitMQ, big‑data collection, storage, processing, and analysis layers for a big‑data platform). The focus is on technology components rather than business functions.

Single‑Application Functional Architecture

Functional 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, or into a technical support layer, application layer, and portal layer.

Logic for Drawing Architecture Diagrams

When creating an overall architecture diagram, start with the cloud three‑layer or SOA three‑layer model for the central part, and add standards, security, quality, and governance layers on the sides. Avoid mixing different diagram styles to prevent confusion.