Mastering Architectural Abstraction: Simplify Complex Systems

Architecture’s core is managing complexity, and an architect’s essential skill is abstraction—the ability to simplify the complicated.

Abstraction means turning a complex matter into something easy to understand, often by using analogies.

How to Train Abstraction Ability?

Three methods are suggested:

Use induction to find commonalities across multiple problems and extract generic solutions.

Use deduction to discover relationships, linking problems into a systematic whole.

Apply induction again to identify distinctive features, continuously clarifying the essence of a matter.

1. Finding Commonality by Induction

There are two ways: identifying common demand and common information.

1.1 Common Demand

When serving billions of users across industries, each industry has personalized needs, but limited technical resources cannot satisfy every variation. Therefore, problems must be converged to find the largest intersecting demand, such as a flexible installment model, and then derive technical services and system architecture from that common need.

For example, many industries want installment financing; by categorizing personalized requirements into standard components (mini‑program, H5, JS), they can be quickly integrated.

At a higher level, common technical goals become: how technology creates a business moat, drives incremental growth, and ensures safe operation.

1.2 Common Information

Modeling extracts invariant information from requirements, forming a domain model that guides architecture.

Different installment products (housing, auto, home‑renovation, e‑commerce) share core elements—credit limit, interest rate, repayment method—combined in various ways.

Similarly, foundational technical commonalities include protocols like TCP/IP, language basics, and data structures, which remain stable for decades.

2. Finding Relationships by Deduction

Deduction helps architects view problems systemically, split into internal and external relationships.

2.1 Internal Relationships

Identify the business lifecycle and the system’s main flow. For installment services, the lifecycle is creation → failure → success → payment closure, with a fixed internal process (authentication, payment, refund).

Understanding these relationships also reveals future demand trends, guiding architectural upgrades.

2.2 External Relationships

Clarify architectural boundaries: what to build, what not to build, core services, and external dependencies. Clear boundaries act like standards, reducing communication complexity.

3. Finding Characteristics by Induction

First, locate commonalities between two businesses. For example, both Huabei payment and Huabei installment share internet‑finance attributes, but differ in payment modes, repayment options, marketing strategies, and service roles.

Similarly, mastering Java requires focusing on its key characteristics—garbage collection and multithreading—rather than trying to learn every detail.

Balancing common and specific needs involves trade‑offs: sometimes prioritize common demands, other times preserve differentiated features to create technical barriers.

4. Conclusion

Solving one problem often creates another, disturbing an existing balance. Effective architects practice “non‑action” by minimizing unnecessary changes, making careful trade‑offs, and maintaining system equilibrium, especially during upgrades that may duplicate work across old and new paths.