Why Good Architecture Should Be Business‑Independent: Real‑World Refactoring Insights

On August 13, 2015, Neeke (Gao Chitao), a senior architect at Yunzhihui and author of PECL/SeasLog, began a sharing session about his experiences in architecture and refactoring of websites, applications, and information systems.

He uses the West Zhi Men overpass in Beijing as a metaphor: the green line shows the desired driving route, while the yellow line shows the actual, more complex route that drivers must follow. Although confusing for drivers, the design benefits traffic police by eliminating the need for signals and reducing accidents.

This analogy leads to a key point: excellent architecture is largely business‑independent; designing solely from a business perspective often leads to failure.

He then compares a deteriorating building to legacy systems that continue to serve users despite being fragile. When developers, operators, and maintainers feel exhausted, it signals that refactoring is needed.

Before refactoring, the focus should be on the "residents" of the old building—the existing business logic—not on adding flashy new components. Ignoring existing business risks turning a refactor into a brand‑new project that cannot keep up with ongoing changes.

Neeke outlines a practical refactoring process based on his experience with large‑scale applications:

Identify and group existing support points (bugs, patches, workflow fixes) that hinder iteration.

Isolate these groups to decouple business logic and reduce risk.

Deeply analyze each isolated point to understand its processes, layers, and critical aspects.

Standardize and replace the support points incrementally, rebuilding the foundational structure step by step.

He emphasizes that rebuilding an entire system from scratch exhausts everyone, whereas dismantling the weak parts of a legacy system and re‑assembling them creates a solid foundation for a successful refactor.

The session concluded with a Q&A where participants discussed the balance between business considerations and technical architecture, the importance of avoiding over‑customization, and practical tips for refactoring distributed systems.