How to Draw a "Universal" Architecture Diagram: Three Core Principles of Architectural Thinking
Technical Solution Communication Methodology
Table of Contents
---
> “A picture is worth a thousand words.”
In daily work, expressing design ideas often involves diagrams. Yet, differences in knowledge, thinking styles, and architectural priorities (e.g., high-concurrency systems, complex B-end systems, big data, streaming, machine learning, client-side) lead to highly varied diagrams.
Without a standardized, universal technical solution communication language, communication can be ambiguous, slowing personal growth and preventing a systematic way of thinking.
This guide condenses years of architectural practice and industry software engineering methodologies into a universally applicable visual communication framework for technical solutions.
---
1. Introduction
Different system types have different complexity emphases. Diagrams should focus on the most relevant complexity for that system type.
This methodology balances effort vs. benefit and draws on:
- Software 4+1 Views
- Domain-Driven Design (DDD)
- Microservice decomposition
- UML
- ER diagrams
System Focus Areas
| System Type | Key Focus Areas |
|-------------|----------------|
| High-traffic consumer systems | System architecture, high concurrency, high availability |
| Complex business-oriented systems (B-end) | Domain modeling, data modeling, microservice decomposition |
| Big data-based business systems | Mass data management, storage/transformation, data consistency |
| Data analysis / algorithmic systems | Data-driven thinking, model & algorithm structure |
Applicability:
This methodology best fits types 1 and 2. Types 3 and 4 mostly benefit from macro-level diagramming.
---
2. Macro Level
Macro-level diagrams set the context and high-level structure.
2.1 Context Diagram
Purpose:
- Show the business and system context.
- Frame your system as a black box and describe:
- Who does your system serve? (users, roles, or other systems)
- Who does your system depend on?
Reference:
Tip:
If context is simple, the Context Diagram can be merged with the System Architecture Diagram.
---
2.2 System Architecture Diagram
Purpose:
- Define system boundaries and responsibilities.
- Show high-level interactions between systems/subsystems.
Approach:
- One diagram showing:
- Cross-team large system interactions
- Internal subsystem interactions
Notes:
- A system/subsystem = cluster (microservice or deployed system).
- Exclude logical modules in the same process.
Optional:
Single-service or monolithic applications with no external interaction can skip this diagram.
---
2.3 Physical Deployment
Purpose:
Correlates to the System Architecture Diagram, showing:
- Single vs. clustered deployment
- High availability
- Shared machine sets
Representation:
Often via a table, e.g.:
| System/Subsystem | Data Center | # Machines | Protocols (HTTP/TCP/UDP) | Notes |
|------------------|-------------|------------|--------------------------|-------|
| Java Microservice 1 | XX | 2 | HTTP | |
| Subsystem 2 | XX | 1 (single) | UDP | |
| ... | ... | ... | ... | ... |
---
3. Medium View
These diagrams describe key structural and interaction details.
3.1 Domain Model vs. Data Model
Domain Model:
- From DDD/UML.
- Describes conceptual entities and relationships.
Data Model:
- ER diagrams.
- Focuses on storage entities and relationships.
Reality:
Strict separation is rarely maintained. If alignment is weak, favor data model clarity.
Checklist:
- Key entities in your system
- Relationships (1:1, 1:N, N:N)
Key Points:
- ER diagrams omit most fields; focus on keys and state.
- KV storage still requires relationship mapping.
- Hybrid KV + DB systems must clarify consistency guarantees.
---
3.2 Sequence Diagram
Common Issues:
- Inconsistent swimlane levels (system, subsystem, module, user).
Best Practice:
- Pick one granularity and use UML conventions.
---
3.3 State Diagram
Purpose:
Model complex state transitions (often tied to DB `state` fields).
Approach:
- Follow UML notation.
---
3.4 Concurrent Runtime View
Purpose:
Show thread/process communication & synchronization.
Mandatory if:
- C++ systems with custom frameworks.
- Describing thread safety, locking, blocking/waking.
Not needed if:
- Standard Java microservices with fixed thread/process models.
---
3.5 Data Flow Diagram (Big Data Systems)
Applies to:
- Offline data pipelines (TDW/HDFS, HBase, subtasks, MySQL, UI).
Purpose:
Map end-to-end data processing flow.
---
4. Micro Level
Detail-oriented specs for development.
- API Documentation
- Interfaces, parameters, data types, error handling.
- Table Design (Full Spec)
- Database & instance ownership
- Detailed field explanations
- Background Tasks
- Number & cycles
- Scheduling type (crontab, quartz, XXL-job, etc.)
- Deployment location vs. services
---
5. Supplementary Notes
Default Assumptions Boost Efficiency:
- API = standardized RPC
- Background Task = standardized distributed scheduling
- Message = standardized message middleware
- DB = standardized DB deployment
By setting common defaults, teams reduce documentation overhead and speed communication.
---
Pro Tip:
For sharing technical documentation across multiple platforms efficiently, teams can integrate distribution and analytics tools. For example, AiToEarn官网 — an open-source global AI content monetization platform — enables simultaneous publishing of diagrams, explanations, and updates to channels like Douyin, Bilibili, LinkedIn, and more, paired with analytics (AI模型排名) to measure engagement and reach.
---
End of Document
