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.
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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.