Principles of Software Architecture: Splitting, Abstraction, and Evolution

Software architecture is likened to building construction: architects design the overall appearance, structural framework, materials, and processes before the foundation is laid, ensuring the building can withstand earthquakes, typhoons, and settlement—paralleling high concurrency, performance, and availability in software.

In software engineering, architectural design defines subsystems, components, deployment methods, technical specifications, and their relationships.

Many people mistakenly think architects only create flashy PPTs, UML diagrams, and module breakdowns without writing code; however, proper design, like military logistics, reduces costly rework.

Key qualities of an excellent architect include:

Business understanding and translation ability

Abstract thinking

Software modeling skills

Designing high‑concurrency, high‑performance, high‑availability distributed systems

Choosing cutting‑edge technologies wisely

System refactoring capability

Rapid learning ability

Familiarity with distributed cache, message queues, load balancing, databases, NoSQL, search, RPC, containers, sharding, registration centers, configuration management, tracing, service governance, monitoring, micro‑services, etc.

Strategic wisdom: “Ignore the enemy strategically, respect the enemy tactically!” and the importance of keeping a broader view to avoid the 木桶效应 (bucket effect).

🌴 1. "Splitting" – Reducing Architectural Complexity

Splitting a system into smaller, manageable parts lowers complexity, weakens coupling, and improves scalability. Benefits include:

Reduced impact of parallel development and releases

Focused expertise and higher professionalism

Weaker module coupling, lowering overall risk

Clear division of labor and higher efficiency

Stateless micro‑service deployment enables horizontal scaling and targeted performance tuning

When splitting, follow these guidelines:

Prefer vertical splitting by business domain and workflow rather than pure technical dimensions.

Further horizontal splitting can use read/write separation, online/offline separation, fast/slow separation, or scenario‑based separation.

Continuously adjust strategies to separate mutable from stable, common from non‑common components.

Splitting is the first step in designing large, complex systems and is a core skill for architects.

🌴 2. Cognitive Abstraction – Reusable Architecture Patterns

Understanding and abstracting concepts allows knowledge to transfer across domains. The classic saying “one mastery leads to many” illustrates that mastering one business domain equips you to handle others.

Modern internet services (IM, e‑commerce, ride‑hailing, search, O2O) may look different but can be abstracted into three categories: read‑oriented, write‑oriented, and decrement‑oriented business.

Read business: high SLA for reads, low write frequency – data is often pre‑fetched ( 数据尽量前置).

Write business: high SLA for writes, data is user‑private and does not depend on existing data (

写业务的特点是写入的数据是用户私有的而不是共享的

).

Decrement business: similar to writes but with much smaller payloads and high concurrent modification requirements; splitting large inventory into smaller buckets reduces pressure ( 可以考虑将大库存拆分N份小库存).

If you know how to handle hot‑search events on Weibo, you can apply similar caching strategies to flash‑sale items in e‑commerce ( 共性化 solutions).

🌴 3. One Picture Is Worth a Thousand Words – Five‑View Modeling

Architects favor diagrams because visual information is easier to digest. The “Five‑View” method describes architecture from different perspectives:

Logical view – functional requirements and system responsibilities.

Development view – source organization, frameworks, build and dependency management.

Runtime view – processes, threads, coroutines, concurrency, synchronization, and communication.

Physical view – deployment infrastructure, servers, networks, and high‑availability considerations.

Data view – data models, schemas, and relationships (often expressed with ER diagrams).

🌴 4. Systems Evolve – From Monolith to Platform to Middle‑Platform

As a company grows, its system evolves: chimney‑style architecture → platformization → middle‑platform.

Early monolithic systems suffer from duplicated modules and high maintenance cost. Platformization merges common modules to improve efficiency. Middle‑platform (enterprise‑level capability reuse) further visualizes business capabilities, allowing rapid configuration and flow definition.

Key steps for middle‑platform construction:

Visualize business capabilities ( 业务可视化平台).

Register business flows in the visual system using connection or workflow rules ( 连线规则, 流程引擎规则).

Ensure the platform reflects code changes in real time, enabling fast business rollout ( 业务快速落地).

When new business scenarios appear (e.g., community group buying), the middle‑platform should quickly reuse existing capabilities.

🌴 5. The “Dao” of Architecture – Aligning with Business and Non‑Functional Needs

Before designing a solution, fully understand business background and customer requirements; otherwise the system will miss the target.

Beyond functional needs, consider non‑functional aspects: target user groups, traffic patterns, potential abusive actions, and required resilience (e.g., handling flash‑sale spikes without collapse).

Design trade‑offs are inevitable: splitting introduces distributed transactions, longer call chains, more modules, increased server count, and higher coordination cost. A good architecture balances current business demands with future extensibility.

In summary, effective software architecture combines holistic thinking, systematic splitting, abstract pattern reuse, visual modeling, and continuous evolution while staying tightly coupled to business realities.