Architectural Growth: How Cognition Upgrade Shapes System Design

There are countless architecture‑related articles online, yet many readers feel lost among terms like SOA, distributed transactions, DDD, and complex system refactoring. The author decides to share personal experiences from years of architectural work at Alipay to help others.

Growth is the upgrade of cognition. To become an architect, one must develop the cognition that underlies architectural ability, which the author defines as the essence of knowledge.

Using a common interview question—"How does Java handle multithreading and concurrency?"—the author contrasts a typical senior answer (using Thread, Runnable, Executors, sync, Lock) with his own answer: "Don’t use multithreading." He explains why multithreading can cause hangs, memory leaks, and unnecessary complexity, and suggests alternatives such as message queues, read‑only access, and domain‑driven design.

The author emphasizes that different levels of understanding lead to different answers, highlighting the importance of asking "why" repeatedly (the 3‑why method) to uncover the root of a problem.

He introduces systematic thinking tools: the MECE principle (mutually exclusive, collectively exhaustive), the 5W2H framework (who, what, when, where, why, how, how much), and the 3‑why method, all aimed at structuring analysis and decision‑making.

Architectural capability is broken down into three parts:

Architecture positioning : defining the high‑level purpose and scope of a system (e.g., transaction system, payment system, accounting core).

Business architecture : describing functional responsibilities, service boundaries, and domain models, often using a three‑layer approach (business scenario, platform product, platform service).

Application architecture : translating business architecture into concrete code structures, such as onion‑layer designs, DSL frameworks, and action‑based modules.

He stresses the need for architecture continuity, ensuring core domain models and layering remain stable while allowing horizontal expansion and technical evolution (e.g., adding platform products without altering the core).

Technical solutions discussed include distributed transaction patterns (TCC, JTA/XA, Saga), idempotency, sharding, high‑concurrency splitting, clustering, multi‑active deployment, distributed locks, and unique‑constraint management, as well as design patterns like ACL, templates, workflow, strategy, AOP, and classic design patterns.

The article concludes that architecture must balance present needs with future trade‑offs, requiring clear goals, core problem focus, and disciplined decision‑making to avoid over‑engineering while still supporting growth.