Fundamentals 15 min read

Layered Thinking and Modeling in Architecture Design

This article explains how layered thinking and layered models guide architecture design, covering decomposition and integration, cloud three‑tier (IaaS‑PaaS‑SaaS) and SOA layering, the role of service and data layers, and how to combine cloud and SOA concepts into coherent architectural diagrams.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Layered Thinking and Modeling in Architecture Design

Architecture Thinking Overview

Architecture thinking is a collection of system, structured, and programming mindsets that bridge business reality and abstract IT implementation; its core is to let technology serve business, balancing requirements, implementation, cost, and benefit.

Decomposition and Integration

Decomposition breaks complex problems into high‑cohesion, loosely‑coupled modules, defining problems based on clear requirements. Integration then assembles these modules through appropriate interfaces, ensuring the whole system functions as a unified whole.

Layered Thinking in Architecture

Layered thinking helps organize a large system into smaller modules and then aggregate them into a complete architecture, making the overall design easier to understand and manage.

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

The standard cloud model consists of IaaS (infrastructure), PaaS (platform services), and SaaS (applications). The resource layer spans physical resources, virtual machines, and containers; the platform layer includes both technical and business platforms (mid‑platform); a service layer between platform and application decouples resources from services.

For IoT scenarios, additional network and perception layers are often added beneath the resource layer.

Question 1: Database and Data Layer

In a complete enterprise architecture there is no dedicated "data layer"; data concerns appear within the technical architecture (e.g., structured/unstructured storage) or as a data platform domain within the PaaS layer.

Question 2: Service Layer and Services

A capability‑open platform or service layer can be defined without enumerating specific business services; it represents the abstraction of service capabilities that can be exposed to applications.

SOA Layering: Component‑Service‑Process

SOA emphasizes an independent service layer, not a service bus, and visualizes components, service domains, and processes. Typical SOA diagrams show components, ten service domains, and five process types.

Cloud and SOA Fusion

Both cloud and SOA share a three‑tier view (resource, service, application). For example, the IaaS resource layer provides APIs (service layer) that enable a public cloud platform (application layer). Similarly, SaaS components map to resources, services, and front‑end functionality.

Application Architecture Layering

The classic three‑tier model consists of User Interface, Business Logic, and Data Access layers, optionally supplemented by a Facade, API, or DTO layer. Domain‑Driven Design adds an Application layer, renames Business Logic to Domain layer, and calls Data Access the Infrastructure layer.

Independent Application Layer Split

The Application layer orchestrates domain services and presents unified capabilities to front‑end applications (web, desktop, or mobile), avoiding duplicated logic across different client types.

Interface vs. UI Layer

Micro‑service modules without UI expose only an API interface layer, which can serve both APP and BS (browser‑based) front‑ends.

Software Technical Architecture Layering

Technical architecture also follows a three‑tier model, focusing on key technology components (e.g., messaging middleware like RabbitMQ, big‑data platforms, etc.). For a big‑data platform, layers may include data collection, storage, processing, analysis, and application.

Single‑Application Function Architecture

Functional architecture divides business into support, execution, and decision‑management layers, or alternatively into support‑technology, application, and portal layers.

Diagram Layering Logic

When drawing architecture diagrams, avoid mixing different layering models; use cloud three‑layer or SOA three‑layer patterns for the core, and add standards, security, and quality layers on the sides.

Diagram Construction Logic

Place standards, security, and quality guidelines on the left/right, and focus the central area on resource, platform, service, and application layers, ensuring a clear, multi‑view architecture.

software architecturearchitecturecloud computingtechnical architectureSOAlayered design
IT Architects Alliance
Written by

IT Architects Alliance

Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.