Layered Architecture Thinking and Models: From Cloud Three‑Tier to SOA and Application Design

Today I discuss layered thinking in architecture design and the logical models that stem from it.

Overview of Architecture Thinking

Architecture thinking is a collection of system, structured, and programming mindsets. Its core is to bridge business reality with abstract IT implementation, ensuring that technology serves business, balancing requirements, implementation, software, hardware, static and dynamic aspects, as well as cost and benefit.

Two key focuses in architecture are decomposition and integration. Decomposition breaks complex problems into cohesive, loosely‑coupled components; integration then assembles those components via appropriate interfaces into a complete system.

Decomposition + integration forms the core architectural method. After decomposition, many small modules must be aggregated to form a complete architecture, which requires layered thinking.

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 focuses on infrastructure and virtualization, PaaS on platform services, and SaaS on concrete applications.

The resource layer spans physical resources, virtualized logical resources, VMs, and containers. The platform layer now includes both technical and business platforms (often called the “mid‑platform”). A service layer between platform and application decouples resources from services.

For IoT scenarios, additional network and perception layers are added, as shown in the smart‑city example.

Question 1: Database and Data Layer

In a complete enterprise architecture there is no dedicated “data layer”; it only appears when describing a single application’s internal layering.

Listing structured and unstructured data as a separate layer in a top‑level diagram is inaccurate; such details belong in the technical architecture.

If common data capabilities are shared across the enterprise, they can be represented as a data platform domain within the PaaS layer.

Question 2: Service Layer and Services

An overall architecture may expose a capability‑opening platform or service layer without enumerating specific business services, which belong to the application layer (or business middle‑platform).

The diagram below illustrates this separation.

The service layer can be seen as a combination of resource, service, and application layers, forming a cohesive architecture.

SOA Layering: Component‑Service‑Process

SOA emphasizes the service layer; components belong to the logical resource layer, while services expose capabilities externally.

When developing with SOA, the system is split into components, service domains, and processes, which should be reflected in the diagram.

In this view the data layer becomes a component layer, and the service layer shows distinct API services (e.g., user‑center, procurement).

Fusion of Cloud and SOA Architecture

The diagram below merges cloud three‑tier and SOA three‑tier concepts, illustrating that each cloud layer can be further split into resource, service, and application sub‑layers.

For example, the IaaS layer provides physical/virtual resources (resource layer) and exposes them via APIs (service layer), which together form a public‑cloud SaaS offering (application layer).

Application Architecture Layering

Classic three‑tier application architecture consists of User Interface, Business Logic, and Data Access layers. Additional layers such as Facade, API, or DTO may be introduced without changing the core hierarchy.

Domain‑Driven Design refines this by adding an Application layer between UI and Domain (formerly Business Logic) and renaming Data Access to Infrastructure, broadening its scope beyond a specific DBMS.

Further fusion of domain models and classic three‑tier yields a technical architecture that separates Component, Service, and Application layers.

Domain Layer vs. Business Logic Layer

Domain models represent business objects; the domain layer implements these objects and exposes business rules as services.

Traditional implementations map each table to a DAO, Service, and Interface, whereas DDD encourages assembling DAO capabilities around domain objects.

Independent Application Layer Splitting

The application layer orchestrates multiple domain services and exposes them to front‑end clients (web, mobile, desktop).

In micro‑service and middle‑platform contexts, this layer consolidates common service composition logic, avoiding duplication across UI implementations.

Interface Layer vs. Presentation Layer

When a micro‑service provides only API interfaces without UI, the topmost layer is the interface service layer, which can be consumed by both app and web front‑ends.

Software Technical Architecture Layering

Technical architecture diagrams also follow a three‑tier model, focusing on key technology components or services rather than business functions.

For large‑scale platforms (e.g., big‑data platforms), the architecture is still layered: data collection, storage, processing, analysis, and application, each with its own technology stack.

Technical stack diagrams can further detail middleware choices (e.g., RabbitMQ for messaging) and other product selections.

Single‑Application Functional Architecture

Functional architecture describes what capabilities an application provides, not how they are technically implemented.

Typical functional layers: foundational support, execution, and decision‑management, which can be further broken down by business domain or lifecycle stage.

Logic for Building Architecture Diagrams

When drawing a complete architecture diagram, separate the diagram into left/right (standards, security, quality, etc.) and a central layered architecture core.

The central part should follow cloud and SOA layering: resource → platform → application, with an optional service layer to decouple resources from applications.

Different stakeholders (developers, operations, product owners) use different views of the same layered architecture, so mixing modeling styles should be avoided.