Refactoring a Complex Backend System: Decoupling Logic, Dynamic Configuration, and Result Isolation

Refactoring is a long‑standing topic, but in large, multi‑team projects reading design‑pattern books is insufficient; developers often face tightly coupled code that is hard to modify when requirements change.

Using JD App's backend as a case study, the author describes a system with many entry sources (App, PC site, mini‑program, etc.) that caused massive if‑else logic and poor isolation, making a change in one feature affect many others.

The original implementation tightly bound the refer parameter to specific business modules, leading to tangled code and maintenance headaches.

To simplify judgment, the solution moves the decision logic into each module via a common interface; the main flow merely iterates over the interface collection, allowing each module to decide whether to execute based on its own criteria.

Dynamic configuration replaces hard‑coded refer==1 checks with values stored in a configuration center (e.g., Zookeeper, etcd). Module activation can now be toggled without code changes or redeployment.

Result‑layer isolation applies the same interface pattern to output fields, letting each field decide whether to be included, thus avoiding a monolithic result‑building block.

Long‑running methods are broken into small, ordered interface implementations; an Order annotation controls execution sequence, and encapsulation keeps related state within a single class.

When a long logic needs early termination, implementations return a boolean; a false value stops further iteration, handling interruptible flows cleanly.

Overall, the refactoring demonstrates how to achieve modular responsibility, configurability, and clean result handling in a complex backend, offering patterns that can be adapted to similar large‑scale systems.