Mastering Layered Architecture: From Cloud Stacks to SOA Integration

Layered Thinking and Modeling in Architecture Design

Architecture thinking combines system, structured, and programming mindsets, acting as a bridge between real‑world business and abstract IT implementation. The core principle is that technology serves business, requiring a balance among requirements, implementation, hardware, cost, and benefits.

Two key actions in architecture are decomposition and integration . Decomposition breaks complex problems into cohesive, loosely coupled modules, starting with clear requirements. Integration then assembles these modules via appropriate interfaces into a complete system; without integration, decomposition is meaningless.

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

The standard cloud stack consists of IaaS (infrastructure), PaaS (platform services), and SaaS (applications). The resource layer evolves from physical assets to virtual machines and containers; the platform layer now includes a business (mid‑platform) layer, and a service layer between platform and application decouples resources from services.

Question 1: Database and Data Layer

In a full‑scale architecture there is no separate “data layer”; data concerns belong to the technical architecture or can be represented as a data platform within the PaaS layer.

Question 2: Service Layer and Services

A dedicated service layer can expose capabilities without detailing individual business services, which belong to the application layer; this aligns with a “technology platform + mid‑platform + application” view.

SOA Layering: Component‑Service‑Process

SOA emphasizes an independent service layer; components reside in the logical resource layer, while services expose capabilities. Typical SOA diagrams show components, service domains, and processes, with the service layer often merged with a component/resource layer.

Integration of Cloud and SOA Layers

Cloud architecture stresses Infrastructure‑Platform‑Application, whereas SOA stresses Resource‑Service‑Application. Traditional systems add middleware and databases, resulting in multiple overlapping layers. Combining both yields a unified model where each cloud layer can be further split into resource, service, and application sub‑layers.

Application Architecture Layers

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

Software Technical Architecture Layering

Technical architecture mirrors the three‑tier model, focusing on key technology components (e.g., messaging middleware like RabbitMQ). For platforms such as big‑data systems, layers may be Data Ingestion, Storage, Processing, Analysis, and Application.

Single‑Application Functional Architecture

Functional architecture describes capabilities rather than technical layers; it can be organized into Support, Execution, and Decision‑Management layers, or into Technical Support + Application + Portal layers, further subdivided by business domains.

Diagramming Logic for Layered Architecture

When drawing an overall architecture, reference cloud three‑layer and SOA three‑layer diagrams, keeping standards, security, and quality guidelines on the sides, and focusing the central view on resource, platform, and application layers, with a service layer mediating between platform and application.