祝融说。

Prologue: A Distress Signal at Three in the Morning

(A note: the "Starfish E-commerce" platform, its characters, timeline, and incidents throughout this book are a synthetic case -- a consolidation of failure patterns that recur across the industry -- rather than a record of any real company.)

At three in the morning, Zhang Wei's phone vibrated abruptly in the silent bedroom, the screen flashing the name of Li Ang, the newly appointed project manager. When he answered, Li Ang's voice carried a barely contained urgency and exhaustion: "Zhang Wei, we have a major incident in production! An operations campaign has locked the accounts of some core users, and the customer service lines are being flooded. We rolled back the code, but the account states haven't recovered. Can you log in and take a look?"

Zhang Wei sighed, threw on a jacket, and powered up his computer. As the company's senior architect, he was long accustomed to these "midnight alarms." When the system runs smoothly, everyone talks about cloud-native, Service Mesh, and AI empowerment. But when the system collapses, the root cause almost always traces back to an inconspicuous if/else statement and an overly "optimized" database field.

Connecting to the production environment, Zhang Wei found the offending code. It was a piece of logic that handled user activity eligibility, anchored by a conditional spanning more than thirty lines, like a giant python coiled into a knot:

// UserActivityService.java
public void processActivity(User user, Activity activity) {
    // ... pre-processing logic
    if (user.getStatus() == 1 && user.getLevel() > 3 && !user.isBlacklisted()) {
        if (activity.getType() == 5 || (activity.getType() == 2 && user.getRegisterDays() > 365)) {
            // ... core activity logic A
        } else {
            // ... compensating logic B
        }
    } else if (user.getStatus() == 2 && user.isVip()) { // temporary VIP channel
        // ... core activity logic C
    } else if (user.getStatus() == 10) { // partner channel users, special handling
        // ... core activity logic D
    }
    // ... post-processing logic
}

Li Ang explained over the conference call: "For this campaign, we wanted old users with status 1 (registered over a year) to be able to join type 2 activities, so we added that user.getRegisterDays() > 365 check. But unexpectedly, it wrongly modified the statuses of some VIP users."

Zhang Wei's gaze didn't linger on the line Li Ang had pointed to. Instead, it fixed on the user.getStatus() method. He had a strong premonition that this was another disaster caused by a "universal field." He searched the entire project for uses of getStatus(), and hundreds of results instantly flooded the screen, scattered across the order, payment, risk-control, and marketing modules.

He opened the definition of the User entity class. Above the status field, comments left by several generations of programmers were piled one on top of another, like a "digital epitaph" etched with the weight of history:

/
 * User Status
 * 1: Normal
 * 2: Pending Activation (early version, deprecated, but has legacy data)
 * 3: Locked (Risk Control)
 * 4: Deleted
 * 
 * -- 2021-05-10 by Alex --
 * Temporarily added status 10: Channel A user, identity verification incomplete
 * 
 * -- 2022-08-15 by Bob --
 * Marketing campaign requirement, added status 11: Campaign Frozen (profile cannot be modified during campaign)
 * 
 * -- 2023-01-20 by Carl --
 * To maintain compatibility with the legacy CRM system, users with status=1 and unverified email are also treated as "Pending Activation." Note this in the code.
 */
private int status;

Zhang Wei's head began to throb. He finally understood where the problem lay. Three years ago, user.getStatus() == 1 meant "a normal, usable user." Today, it meant "a user who is neither pending activation, locked, deleted, nor in Channel A or campaign-frozen, and who additionally requires a check on whether the email is verified."

Li Ang, the new developer, was like a worker building a house on the ruins of ancient Rome. He saw only the flat stone on the surface (status == 1) and confidently laid his walls upon it, unaware that beneath that stone lay the forgotten foundations of three different urban eras. His small change unintentionally disturbed a deep structural fissure, bringing the whole edifice tumbling down.

This is the state of most of our software systems -- an "archaeological site" in code. Every maintainer acts like a cautious archaeologist, facing layer upon layer of logical strata, trying to infer from the crumbling walls (if/else) and magic numbers the true intentions of some product manager from years or even a decade ago. They dare not dig recklessly, because no one can say whether removing a seemingly useless stone might cause the entire tomb to collapse.

This book is about putting an end to this endless "technical archaeology." Together, we will explore why we hand-build these sprawling "ruins" in the first place, and how to dismantle them at their root -- through data design -- so that our systems can be reborn.

Before we begin, a word on where this methodology comes from. It is not an isolated collection of experience, but an extension of the RC theoretical system (Process Realism: Observational Convergence and the Generation of Determinacy) into software engineering: the "determinacy" in a software system -- code, fields, state machines -- is a secondary construction under some act of observational convergence, and a field forced to answer multiple business questions at once is precisely the projection of the theory dimension-reduction principle onto data modeling: carrying high-dimensional business in a low-dimensional carrier inevitably produces an explanatory gap, and that gap gets buried in code as if/else. The "conceptual compression" and "conceptual decompression" of this book correspond to the "bidirectional representation of language" in RC's epistemology -- the compressed field is a projection that saves storage, while the decompressed fields are a "re-observation" that reduces cognitive loss. The through-line of this book -- trading redundancy for fault tolerance, keeping options alive -- is the implementation of RC's practical thesis of "sustainable decision-making" in data design: giving every independent concept its own evolutionary path is preserving its available margin. Readers interested in the philosophical foundations may trace back from that entry point.

It all begins with re-examining a principle we once held sacred: "reuse."

Section 1: Code Geology -- Why Every if/else Is a Forgotten Piece of Business History

In software development, we habitually treat if/else as the most basic unit of logical control. But if we stretch the dimension of time and view it from the perspective of system evolution, if/else is far more than a branch in the code. It is the solidification of a business decision, a snapshot of a requirement at a particular moment in time, a "business fossil" buried deep within the code strata.

Let us coin a term for this phenomenon: code geology. Just as geologists reconstruct the history of the Earth by analyzing rock strata, we can reconstruct a software system's evolutionary history by analyzing the stacked layers of if/else in its code.

Geological Age One: Genesis

Imagine we are building an entirely new e-commerce system. In version 1.0, the business is pure: users place orders, pay, merchants ship, and orders complete. We design an order table, t_order, with a core field status.

t_order table (V1.0):

• id
• user_id
• amount
• status (1: Pending Payment, 2: Paid, 3: Shipped, 4: Completed)
• create_time

At this point, the code is clear as crystal, like the freshly formed surface of a new geological stratum:

// OrderService.java (V1.0)
public void shipOrder(long orderId) {
    Order order = orderRepository.findById(orderId);
    if (order.getStatus() == 2) { // Only "Paid" orders can be shipped
        // ... shipping logic
        order.setStatus(3);
        orderRepository.save(order);
    } else {
        throw new IllegalStateException("Incorrect order status, cannot ship");
    }
}

This if statement is the first law of this business world -- simple, clear, and beyond question. It embodies the self-evident commercial model of "pay first, ship later."

Geological Age Two: The Ice Age -- The First Mutation

As the business grows, the company introduces a "Cash on Delivery" model. The commercial rules change. The product manager says: "We need a new order type where users place the order first, we ship it, and they pay upon receipt."

After discussion, the engineering team proposes two options:

1. Option A (add a field): Add a payment_type field to the t_order table (ONLINE_PAY, CASH_ON_DELIVERY).
2. Option B (reuse the status): To "save" on fields, we could add a new value to status, such as 5: Cash on Delivery, Pending Shipment.

In an era when storage was still treated as precious, or in a team that prized "minimal" design, Option B often sounds more appealing. It avoids modifying the table structure and looks like a "smaller" change. So the team chooses Option B.

The meaning of status expands:

• 1: Pending Payment
• 2: Paid
• 3: Shipped
• 4: Completed
• 5: Cash on Delivery, Pending Shipment

Now the first fold appears in the code strata of the shipping logic:

// OrderService.java (V2.0)
public void shipOrder(long orderId) {
    Order order = orderRepository.findById(orderId);
    // The logic begins to diverge
    if (order.getStatus() == 2 || order.getStatus() == 5) { // "Paid" or "Cash on Delivery" orders can be shipped
        // ... shipping logic
        if (order.getStatus() == 2) {
            order.setStatus(3); // Online payment orders become "Shipped" after shipping
        } else { // status == 5
            // What status should a cash-on-delivery order take after shipping? Let's just call it "Shipped" for now
            order.setStatus(3); 
        }
        orderRepository.save(order);
    } else {
        throw new IllegalStateException("Incorrect order status, cannot ship");
    }
}

Notice this || operator. It is the first trace left behind by a tectonic shift (a change in business requirements). It tells us that the concept of "can be shipped" is no longer determined by a single business fact (paid), but jointly by two business facts from different sources (online payment completed, cash-on-delivery order placed).

What's worse, a nested if appears. It exposes a deeper problem: although both cases can be shipped, their subsequent lifecycles are completely different. The status status=3 (Shipped) now becomes ambiguous. For an online payment order, it means awaiting receipt; for a cash-on-delivery order, it means awaiting payment collection. A single status value begins to carry a dual meaning.

This is the first piece of business history to be buried. When a future developer sees if (order.getStatus() == 3), they must work backward through the code like an archaeologist to determine whether this particular "Shipped" state still needs payment collection.

Geological Age Three: The Cambrian -- The Explosion of Life and the Entanglement of Logic

The business enters a phase of rapid expansion. New species (requirements) emerge without end:

• Pre-sale orders: Users pay a deposit first; the balance must be paid before shipping.
• Refund flow: Users can apply for a refund after "Paid" or "Shipped."
• Group-buying orders: The order is valid, and can enter the payment flow, only after the group is fully formed.

The team continues the "fine tradition" of "reusing status," and the "fossil catalog" of the status field grows ever longer:

• ...
• 6: Balance Pending (Pre-sale)
• 7: Group Formed, Pending Payment (Group Buy)
• 8: Refund in Progress
• 9: Refund Completed
• ...

Now let's look at a brand-new requirement: calculating the system's "Effective GMV (Gross Merchandise Value)." The product manager defines it as: "All order amounts that will ultimately result in actual transactions count as effective GMV. But refunded ones should be excluded."

A deceptively simple requirement plunges Xiao Wang, the developer responsible for reporting, into deep thought. He must write logic like this:

// ReportService.java
public Money calculateGmv(Date startTime, Date endTime) {
    List<Order> orders = orderRepository.findByTimeRange(startTime, endTime);
    Money totalGmv = Money.ZERO;
    for (Order order : orders) {
        // This code is a living "Museum of Business History"
        if (order.getStatus() == 2 ||    // Paid
            order.getStatus() == 3 ||    // Shipped
            order.getStatus() == 4 ||    // Completed
            order.getStatus() == 5 ||    // Cash on Delivery, Pending Shipment
            order.getStatus() == 6) {    // Balance Pending (deposit paid, also counts as GMV)
          
            // Exclude refunded orders
            if (order.getStatus() != 8 && order.getStatus() != 9) {
                 totalGmv = totalGmv.add(order.getAmount());
            }
        }
    }
    return totalGmv;
}

Take a close look at this if. It is no longer a line of code; it is a fragile archaeological map. Every number joined by || is the coordinate of a forgotten business scenario.

• status == 2: The original online payment scenario.
• status == 5: A relic from the cash-on-delivery era.
• status == 6: Evidence of the pre-sale model's expansion.

This code has a fatal weakness: it depends heavily on the developer's "historical knowledge."

If, one day, the company launches a new "Enterprise Monthly Billing" business and adds a status 12: Monthly Billing, Pending Shipment, and if the developer responsible for that new business forgets to update this reporting function, the company's GMV report will contain statistical omissions -- an error that might not be discovered by finance until months later.

The accumulation of if/else is, in essence, using the programmer's brain to bear the responsibility that the database should inherently shoulder: recording facts. It forcibly couples together business rules implemented by different people at different times. Every maintenance effort demands that the developer fully "replay" the system's entire evolutionary history in their mind -- a colossal and costly cognitive burden.

Section 2: The Trap of "Reuse" -- When a Single Field Carries Four Meanings

In the previous section, we saw how the status field evolved, amid changing requirements, from a clear marker into a murky swamp. The culprit behind this process is the very software development tenet we have long believed in: "reuse."

The DRY (Don't Repeat Yourself) principle tells us not to repeat code, which is undoubtedly correct. But we often mistakenly extend this principle to the data level, turning it into "don't repeat fields" and "don't repeat data." We become obsessed with third normal form (3NF), striving to eliminate all data redundancy and express the richest business information with the fewest fields.

This extreme pursuit gives birth to an anti-pattern we see everywhere: the "Swiss Army Knife field."

A "Swiss Army Knife field" is usually an int, smallint, or varchar field that looks small and efficient. Like a Swiss Army Knife, it is designed to handle all manner of seemingly related but fundamentally different tasks. It can be a screwdriver, a bottle opener, and a pair of scissors all at once. Yet anyone who has actually used a Swiss Army Knife knows that each of its functions is a poor imitation of a specialized tool. You wouldn't use one to assemble a computer or tailor a garment.

The same is true of "Swiss Army Knife fields" in code. They try to play four completely different roles within a single field:

1. Lifecycle status
2. Access-control dimension
3. Process-trigger beacon
4. Statistical classification tag

Let's return to the user.status example from the opening and dissect how this field came to shoulder all four identities at once.

Role One: Lifecycle Status

This is the field's original purpose at creation -- its most "legitimate" identity. A user passes through a series of core states from registration to deletion.

• status = 1: Normal
• status = 2: Pending Activation
• status = 4: Deleted

These states describe the core evolutionary process of the business entity (the user) itself. They are mutually exclusive: a user can be in exactly one lifecycle state at a time. This is the cleanest, most reasonable usage. If the status field had only ever carried this single meaning, it would be a model of "data modeling."

But disaster begins with the first "reuse."

Role Two: Access-Control Dimension

With the introduction of risk-control requirements, status = 3 (Locked) appears. On the surface, being "locked" also seems like a user state. But if we dig one layer deeper: what is the real business meaning of "locked"?

It means: "This user cannot log in," "This user cannot place orders," "This user cannot post comments."

This is fundamentally an access-control problem. It does not describe what the user is, but what the user can do. The lifecycle state answers "Who is the user?", while the access-control dimension answers "What can the user do?" These are two entirely orthogonal concepts.

Compressing access-control information into the status field directly caused the first decay in the code. Now every place that needs to determine whether a user can perform an action must include a check on status.

Poor design (current state):

// LoginService.java
public void login(String username, String password) {
    User user = userRepository.findByUsername(username);
    // Here, status is being used for access control
    if (user.getStatus() == 3) {
        throw new AccessDeniedException("User is locked");
    }
    // ... login logic
}

// OrderService.java
public void createOrder(User user, OrderRequest request) {
    // Here again, status is used for access control
    if (user.getStatus() == 3) {
        throw new OperationNotAllowedException("Locked users cannot place orders");
    }
    // ... order placement logic
}

A more reasonable design (conceptual decompression):

We should separate these two concepts. The User table should have independent fields to describe its access-control state.

t_user table (improved):

• id
• username
• lifecycle_status (1: NORMAL, 2: PENDING_ACTIVATION, 4: DELETED)
• is_login_locked (boolean)
• is_trade_locked (boolean)

Improved code:

// LoginService.java
public void login(String username, String password) {
    User user = userRepository.findByUsername(username);
    if (user.isLoginLocked()) {
        throw new AccessDeniedException("User is locked");
    }
    // ... login logic
}

// OrderService.java
public void createOrder(User user, OrderRequest request) {
    if (user.isTradeLocked()) {
        throw new OperationNotAllowedException("Locked users cannot place orders");
    }
    // ... order placement logic
}

See the difference? By adding a single boolean field, we made the code's intent utterly clear. The field name isLoginLocked "speaks" for itself; it is self-explanatory. By contrast, status == 3 is a cipher that needs "translation," its meaning hidden in a distant entity-class comment. More importantly, we have separated "login lock" from "trade lock." If a more granular risk-control requirement arises in the future -- say, a "comment lock" -- we simply add an is_comment_locked field, without inventing a new status value or worrying about breaking existing login and transaction logic.

Reusing the status field to express access control was the first conceptual compression. Its cost: the system's access-control logic scattered across the codebase like dandelion seeds.

Role Three: Process-Trigger Beacon

Now let's look at status = 11 (Campaign Frozen). The business meaning of this state is: "During a certain marketing campaign, to prevent users from arbitraging, profile modification is temporarily prohibited."

This state is more peculiar still. It is neither a permanent lifecycle state nor a general access-control mechanism. It is a temporary marker, tightly coupled to a specific business process. It exists to send a signal to some external system (a scheduled task, a message-queue consumer, and so on).

• Scheduled Task A (campaign start): Scans all users matching the campaign conditions and sets their status to 11.
• UpdateProfileService: before performing a modification, checks if (user.getStatus() == 11) and rejects the operation if so.
• Scheduled Task B (campaign end): Scans all users with status 11 and restores their status to 1.

This is a textbook "process beacon." It is like sticking a Post-it note on the user that reads: "Campaign in progress, do not disturb." When the campaign ends, the note is torn off.

Compressing such a temporary beacon into the status field brings two serious problems:

1. Status pollution: The user's core status is "contaminated" by a transient marketing campaign. During the campaign, does this user count as "normal" or not? No one can say. If a GMV statistics task happens to run at this moment, it may inadvertently exclude this user because status != 1.
2. Process coupling: UpdateProfileService now has to "know" about the existence of the marketing campaign. It is forced into coupling with a business process unrelated to its core responsibility (managing user profiles). If there are someday "Double 11 Freeze" and "Chinese New Year Freeze" campaigns, the code in UpdateProfileService will become if (status == 11 || status == 15 || status == 18), gradually "learning" the company's entire annual marketing calendar.

A more reasonable design (decompress again):

Process beacons should be recorded in dedicated, lifecycle-aware tables.

t_user_process_lock table:

• id
• user_id
• lock_reason (e.g., 'ACTIVITY_2024_MID_YEAR')
• lock_type (e.g., 'PROFILE_UPDATE')
• start_time
• end_time
• is_active

Improved code:

// UpdateProfileService.java
public void updateProfile(User user, ProfileData data) {
    // Check whether an active process lock exists
    if (processLockRepository.existsActiveLock(user.getId(), "PROFILE_UPDATE")) {
        throw new OperationNotAllowedException("Profile cannot be modified during the campaign");
    }
    // ... profile update logic
}

This design fully decouples temporary processes from the user's core state. UpdateProfileService no longer cares which campaign it is; it cares only about one business fact: "Is this user's profile-modification feature currently locked?" All locking logic is managed by a dedicated ProcessLockService. The marketing department can create any number of locking strategies freely, without ever needing to "bother" the core user-center code.

Reusing the status field to express processes was the second conceptual compression. Its cost: core services became coupled to countless transient, volatile business processes, until they were no longer recognizable.

Role Four: Statistical Classification Tag

Finally, let's look at status = 10 (Channel A user, identity verification incomplete). Behind this state lies this business story: the company partners with Channel A to acquire users. These users, after registering, enter a special "intermediate state": they can browse but cannot trade until they complete identity verification. The marketing department needs a daily count of "users acquired from Channel A who are pending conversion."

This status = 10 perfectly satisfied the requirement at the time. SELECT COUNT(*) FROM t_user WHERE status = 10 -- one simple SQL, and the report was done.

Yet again, this was a dangerous "reuse." "Coming from Channel A" and "identity not verified" are themselves two independent dimensions of information.

• Source channel: an attribute of the user's origin. A user may come from Channel A, Channel B, organic traffic, and so on.
• Verification status: a state of the user's certification. A user may be unverified, pending verification, or verified.

Forcing these two dimensions together, using status = 10 to represent the combination (Channel=A AND Verification=Unverified), is what we call a "logical Cartesian product."

The short-term benefit of this compression is simple queries, but the long-term cost is catastrophic:

• Combinatorial explosion: If the company later opens up Channel B, which also has an identity-verification flow, must we add a status = 12 for (Channel=B AND Verification=Unverified)? If a "degree verification" dimension is added later, the number of statuses will grow exponentially.
• Difficult queries: One day, the product manager asks for "a count of all users with incomplete identity verification, regardless of channel." The query becomes SELECT COUNT(*) FROM t_user WHERE status = 10 OR status = 12 OR .... Every new channel added requires modifying this query.
• Information loss: When a user with status = 10 completes identity verification, their status is changed to 1 (Normal). At that moment, we permanently lose the valuable information that they "came from Channel A." The marketing department can no longer perform long-term channel-attribution analysis.

A more reasonable design (the ultimate decompression):

We must embrace a counterintuitive truth: for the sake of clean code, we must embrace data redundancy (here, adding fields -- not duplicate data that violates normalization).

t_user table (final version):

• id
• username
• lifecycle_status (Enum: NORMAL, PENDING_ACTIVATION, DELETED)
• access_control (JSON/Flags: {login_locked: false, trade_locked: true})
• source_channel (Varchar: 'CHANNEL_A', 'ORGANIC')
• verification_status (Enum: NONE, PENDING, VERIFIED)

Now, with four independent fields (or field groups), we clearly describe the user's four independent dimensions. Let's see what those earlier, complex queries and logic have become:

• Query all pending-conversion users from Channel A: WHERE source_channel = 'CHANNEL_A' AND verification_status = 'NONE'
• Query all users without identity verification: WHERE verification_status = 'NONE'
• Determine whether a user can log in: user.getAccessControl().isLoginLocked()
• Determine whether a user is in a campaign freeze period: query the t_user_process_lock table.

The code and the queries become as plain as natural language. We no longer need to "decode" the meaning of status=10. The data tells the business story by itself. We added a few fields, and in return the cognitive cost of the entire system plummeted.

This is the trap of "reuse." We thought we were saving storage, but in truth we were recklessly overdrawing the "cognitive bandwidth" of future teams. Every reuse of a "Swiss Army Knife field" buries one more "fossil" -- harder to read than the last -- for the code archaeological site of the future.

Section 3: Cognitive Cost vs. Storage Cost -- The Reversal of Modern Software Development Economics

Why are anti-patterns like the "Swiss Army Knife field" so pervasive, even regarded as "reasonable" design by many experienced developers?

The answer lies in the fact that the economic model of software development costs in our heads is severely outdated. We are building 21st-century complex systems with a set of values from the 1980s. The core premise of this outdated model is: storage is expensive, CPU is relatively cheap, and human time (cognitive cost) is negligible.

The Old Economics: The "Golden Age" of Storage

Let's take a time machine back to the era of mainframes and minicomputers.

• Storage cost: Hard drives and memory, measured in megabytes (MB), were priced like gold. A database administrator (DBA) who could save a single INTEGER field (4 bytes) on a table of ten million records by optimizing normalization would save the company tens of megabytes of storage in a year -- a substantial expense at the time. So the first priority of database design was to eliminate data redundancy and not waste a single byte. Third normal form (3NF) and Boyce-Codd Normal Form (BCNF) were not merely theoretical elegance; they were economic necessity.
• CPU cost: Although CPUs were also expensive, their cost was "one-time." Once a machine was purchased, making it do a little more computation (say, joining several highly normalized tables with JOIN and assembling business objects in memory) seemed more cost-effective than adding storage hardware.
• Cognitive cost: In that era, software business logic was relatively simple and stable. A core system's lifecycle could span a decade, with requirement changes measured in "years." A programmer could spend months fully mastering a module's logic. The "cognitive cost" of code written to save storage (such as using bitwise operations to pack eight boolean flags into a single byte) was paid only once, at the time of learning and writing; the subsequent maintenance burden was not heavy.

Under this economic model, a design like user.status was "genius." It used a 4-byte integer to encode lifecycle, access-control, process, classification, and other information -- a paragon of "space efficiency." Those complex if/else statements were merely making the "cheap" CPU run a few more cycles.

The New Economics: The "Diamond Age" of Cognition

Now let's return to today -- an era dominated by cloud computing, big data, and agile development. The economic model of software development has been turned utterly on its head.

• Storage cost: approaches zero. Let's do a simple calculation (a worked example, for order-of-magnitude illustration). Take mainstream cloud general-purpose volumes: in US regions the price is roughly $0.08 per GB per month (see AWS EBS gp3 pricing), and comparable tiers from Chinese providers are on the order of a few tenths of a RMB per GB per month. Recall our earlier discussion of splitting status into four fields: lifecycle_status (int), is_login_locked (bool), source_channel (varchar), verification_status (int). Suppose this adds 20 extra bytes. For a system with 100 million users, the total additional storage is 20 bytes * 100,000,000 = 2,000,000,000 bytes ≈ 2GB. The monthly cost of this extra 2GB is on the order of single-digit RMB.
• CPU cost: still cheap. Cloud computing makes compute power as accessible as running water, with an extremely low marginal cost. A few extra database queries to simplify code, or a few additional simple objects handled in memory, are practically negligible to a modern CPU.
• Cognitive cost: becomes the most expensive asset. This is the pivotal shift.
  • What is cognitive cost? It is the total mental effort a developer must expend to understand a piece of code, make a correct modification, and feel confident releasing it to production. It includes: the time spent reading code, the difficulty of understanding business history, the effort of reproducing a problem locally, the psychological pressure of fearing side effects, and the cost of fixing production bugs caused by misunderstanding.
  • Why has it become so expensive? 1. Skyrocketing business complexity: In modern internet businesses, requirements iterate on a weekly or even daily basis. Code lifespans are extremely short, and logic changes are extremely frequent. 2. Team mobility: Staff turnover is the norm. A new joiner has no time for "archaeology." Code must be highly "self-explanatory," enabling them to get up to speed quickly and contribute safely. 3. Distributed systems: Under a microservices architecture, a single business process spans multiple services. If every service is filled with "Swiss Army Knife fields" that must be "decoded," then cross-service joint debugging and troubleshooting become a nightmare.

Now let's re-evaluate the user.status problem with this new economic model.

To save a single-digit-RMB monthly storage cost, what did we pay?

• Development cost: Newcomer Li Ang could not quickly grasp the full meaning of status == 1. One of his modifications triggered a production incident.
• Incident cost: The entire technical team (including senior architect Zhang Wei) spent hours in the middle of the night on an emergency fix. The payroll cost of those few hours of engineering time could reach thousands or even tens of thousands of RMB.
• Business loss: Core user accounts were locked, leading to user churn and damaged brand reputation. This loss is incalculable.
• Opportunity cost: Zhang Wei and Li Ang could have spent that time developing new features and creating more value for the company. Instead, they were paying the price of a "cost-saving" decision made years ago.
• Maintenance cost: Every future developer who touches user status must repeat Zhang Wei's "archaeological" process -- careful, as if walking on thin ice. The team's development velocity will be dragged down, and the system will grow more fragile, until one day no one dares to touch it.

The storage cost of adding one field is far less than the cognitive cost of maintaining a tangled mass of if/else.

This seemingly simple sentence is the cure this book offers to modern software development. We must complete the switch in this economic model at the root of our thinking. We must recognize that today, the most precious resource is no longer disk space, but the developer's limited, non-renewable attention.

Our architectural decisions, database designs, and code standards should all revolve around a single core goal: minimizing the system's cognitive cost.

To achieve that goal, we must bravely challenge the seemingly self-evident "best practices." We must learn to "waste" storage for the sake of clarity, add fields for the sake of readability, and duplicate data for the sake of maintainability.

Chapter Summary: Farewell to Archaeology, Become an Architect

In this chapter, we set out from a synthetic midnight production incident and embarked on an "archaeological journey" through legacy code.

We introduced the concept of "code geology," revealing that every if/else is a layer of business history sediment. These stacked layers of logic turned our codebase into a fragile, sprawling "archaeological site," making every maintenance effort fraught with risk.

Next, we dissected the root of it all: the abuse of the "reuse" principle. We saw how an innocent-looking status field was twisted into a "Swiss Army Knife," carrying four entirely unrelated concepts at once: lifecycle, access control, process, and statistics. This "conceptual compression," seemingly efficient in the short term, buried enormous technical debt for the system's long-term evolution.

Finally, we examined the deeper force driving this flawed design: an outdated economic model of software development. We still subconsciously overestimate the cost of storage and gravely underestimate the cost of cognition and communication. By contrasting the cost structures of the old and new eras, we arrived at one of this book's core arguments: in modern software engineering, the engineer's cognitive bandwidth is the scarcest and most precious resource. Our design decisions must shift from "saving space" to "saving brainpower."

Step Out of the "Archaeological Site"

By now, you may feel somewhat disheartened, even seeing the shadows of countless status fields in your own codebase. Please don't be. Identifying the problem is the first step to solving it. The purpose of this book is not to condemn the past, but to build for the future.

We no longer need to play the "archaeologist," timidly deciphering "code fossils" from a bygone era. We should become true "system architects."

A good architect, when designing a building, clearly draws the load-bearing walls, functional zones, and utility lines. He would never run the bathroom's sewage pipe through the master bedroom's load-bearing wall just to save a little space. He knows that this kind of "reuse" would bring endless trouble to the building's future occupants, and make any renovation exceptionally difficult and dangerous.

In software design, data is our load-bearing wall and our utility line.

• An independent field is a pipe with its purpose clearly marked.
• An independent table is a room with a clearly defined function.
• A boundary between systems is a solid load-bearing wall.

When we try to make a single pipe (a field) carry electric power, gas, and network signals all at once, what we are hand-building is a chaotic system that could explode at any moment.

The chapters that follow will hand you a complete "architectural" methodology. We begin at the microscopic field level, learning how to use a "dimension-decomposition method" to separate wrongly compressed concepts. Then we move to the mesoscopic table-structure level, exploring how to use "snapshot patterns" and "separation of concerns" to build systems that can traverse time and answer "why." Finally, at the macroscopic system-boundary level, we learn how "double-ledger" and "reconciliation" mechanisms can establish trust in a distributed world.

Our goal is clear: to eliminate the complexity of code logic through the refactoring of data design.

We will learn how to replace adding an if with adding a column, and how to avoid modifying an old service by creating a new table. This may seem to contradict the "simplicity" intuition we have cultivated for years, but you will soon discover that it is the open road to a genuinely simple, maintainable, change-embracing, elastic system.

Now, close this "archaeology journal," put on your hard hat, and pick up your blueprints. In the next chapter, our construction journey begins in earnest. Our first stop: dismantling the most dangerous "universal fields" and refactoring the most microscopic -- and most critical -- infrastructure in our systems. Deep in the theory of "conceptual compression," we will find the key to "decompression."