Master a Universal Technical Architecture Diagram Language for Any System

Preface

In daily work we draw many diagrams to express design ideas, but due to differing knowledge and system focus (C‑end high‑concurrency, B‑end complex business, big‑data offline, streaming, machine‑learning, client), the diagrams become inconsistent, lacking a standardized “technical solution communication language”, causing ambiguity and hindering systematic thinking.

The author summarizes years of architecture practice and software‑engineering methods into a relatively universal communication language, referencing the C4 model, 4+1 view, DDD, UML, ER diagrams, and more.

Macro

1.1 Context diagram – shows business and system background, who the system serves and its dependencies.

1.2 System architecture diagram – clarifies each system’s position, responsibilities, and inter‑system interactions.

1.3 Physical deployment diagram – maps clusters or single‑process deployments to the architecture diagram.

Mid‑view

2.1 Domain vs data model – domain model (DDD/UML) versus data model (ER); strict separation is often difficult, so the focus is usually on the data model.

2.2 Sequence diagram – use UML to describe cross‑team or intra‑system interactions.

2.3 State diagram – essential for systems with complex state transitions.

2.4 Concurrency runtime view – describes multithread/multiprocess communication within a process (the 4+1 runtime view).

2.5 Data flow diagram (offline big‑data processing) – illustrates long data pipelines involving TDW/HDFS, HBase, sub‑tasks, Java/C++, MySQL, UI, etc.

Micro

Details omitted as they are familiar.

Supplement

A standardized technical system reduces documentation complexity and communication difficulty. The article emphasizes that “interface” defaults to standardized RPC, “background task” to distributed scheduling, “message” to middleware, and “DB” to a standardized deployment.

1. C‑end high‑traffic, high‑concurrency systems – focus on architecture, high availability, and scalability.

2. B‑end complex business systems – focus on domain modeling, data modeling, and micro‑service decomposition (type 1: many upstream/downstream systems; type 2: complex internal logic).

3. Big‑data driven business systems – focus on massive data processing, storage, transformation, and consistency.

4. Data‑analysis and algorithm‑model systems – focus on data‑driven logic, models, and algorithms.