Mastering System Architecture: A Proven Methodology for Building Robust Applications

Alibaba senior technical expert Liu Zhu presents a detailed architecture methodology aimed at helping engineers perform architecture work at various granularities and levels.

Background

Many products repeatedly rebuild from scratch due to improper architectural methods, akin to adding floors on a crooked building.

What Is Architecture?

Early experiences with lighttpd, squid, and Tomcat formed an intuitive notion of architecture, later refined through middleware and application development.

Architecture is defined by ISO/IEC 42010:2007 as "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

Clear responsibilities for modules or components

Explicit relationships between components

Constraints and guiding principles

Architecture Classifications

1. Product Function Architecture – focuses on what the product can do, targeting end‑users.

2. Business Capability Architecture – describes business modules and their capabilities for analysts and planners.

3. Application Logic Architecture – defines modules, responsibilities, and reuse for developers.

4. Application Physical (Deployment) Architecture – maps logical modules to deployment units, considering containers, cross‑region deployment, stability, performance, and cost.

5. Infrastructure Architecture – selects middleware, storage, monitoring, and alerting components.

Capability vs. Responsibility

Capability refers to what a product can do (for users), while responsibility describes the duties of internal modules (for developers).

Deriving Architecture: Two Approaches

Top‑down derivation starts from a well‑defined problem statement; bottom‑up derivation builds from use‑cases and domain models.

需求分析，架构实现，（新需求，架构改动）* n  =  推倒重来。

Bottom‑up derivation involves iteratively extracting use‑case collections, inferring relationships, and aggregating sub‑domains.

Model Levels

1. Business Concept Model (problem space) – focuses on concepts without implementation details.

2. System Model (solution space) – represents classes and logical entities for software design.

3. Storage Model – physical data entities for persistence.

Model Derivation Steps

Derive business concept model from use‑case collections.

Infer relationships using verbs and quantifiers.

Group sub‑domains based on responsibilities.

Induction and Cohesion

Induction aggregates results into higher‑level concepts, ensuring high cohesion and low coupling. Metrics such as "link count / model count" help evaluate cohesion.

Business Process Integration

Business processes define boundaries and exception flows, crucial for accurate architecture.

Logical Architecture Derivation

Combines business concept architecture, system models, and processes, plus non‑functional considerations (performance, stability, cost).

Examples include deriving modules from Spark’s SQL parser flow and optimizing reporting workloads with intelligent cubes.

Non‑Functional Module Derivation

Performance‑driven modules may involve pre‑aggregation (e.g., using Kylin) or adopting high‑performance storage engines.

Summary of Derivation Paths

Business Concept Architecture – from business models and processes.

System Model – from business concepts.

System Process – from business workflows.

Non‑Functional Support – from performance, stability, and cost requirements.

Each path provides concrete methods to construct a robust application logic architecture.

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

For further reading, scan the QR code below or click the links provided.