Evolution and Service‑Oriented Refactoring of a Sales System Architecture

Abstract Architecture evolves alongside business growth; the rapid expansion of sales functions has made the original system unable to meet requirements. This paper examines optimization of the sales system across data, service, and application layers, applying service‑oriented design and outlining future prospects.

Background The sales direction provides tools and platforms to improve salesperson efficiency, as shown in the product panorama (image). Continuous business updates and staff turnover have turned the architecture from a single‑module application into a tangled multi‑module network, accumulating technical debt such as unregulated inter‑module calls, duplicated logic, oversized modules, poor data‑model design, inconsistent code quality, and insufficient monitoring and governance.

2.1 Sales Architecture Data Layer – Personnel Architecture Refactor The sales architecture underpins permission node management for various services. It forms a multi‑branch tree (business region → city → area → circle group → circle) where a salesperson may hold multiple nodes. The original design scattered logic across modules, duplicated code, and stored each level in separate tables, leading to high maintenance cost. Refactor actions include consolidating all levels into a single table, exposing rich APIs, adding an adaptation layer for unified service calls and monitoring, and updating upstream applications.

(1) Redesign the multi‑tree storage into a single table. (2) Encapsulate a data‑service layer with comprehensive APIs. (3) Provide an adaptation layer for uniform service invocation and monitoring. (4) Refactor upstream applications (sales, operations backend, merchant side, anti‑fraud, ranking, etc.).

2.2 Application Layer – Decoupling the Monolithic Module Although some functions have already been extracted, many remain in a large monolith, causing strong coupling, high maintenance cost, slow deployment, and extensive testing. Splitting the monolith into relatively independent small modules, standardizing common components, and horizontal decomposition reduces complexity and aligns services with business granularity.

2.3 Service Layer – Adding a Dedicated Service Layer Established SOA practices (e.g., Dubbo, HFS, Caral) and modern micro‑service principles guide the refactor. Services are divided by functional independence, adhering to single‑business‑principle, resulting in reusable, loosely‑coupled components such as visit, attendance, task, notification, and logging services. The before/after architecture is illustrated (image).

Despite benefits, the service‑oriented architecture introduces challenges:

(1) Performance : Remote calls add latency, data packing/unpacking, and increase failure probability. (2) Transaction Consistency : Distributed services break the atomicity of local transactions. (3) Service Granularity : Determining optimal service boundaries is non‑trivial. (4) Overall Complexity : Distributed calls, monitoring, SLA guarantees, and fault isolation raise operational difficulty.

To mitigate these issues, comprehensive service governance is applied, covering:

Service Documentation Library : Standardize development, usage, division principles, protocols, and data formats.

Priority Call Management : De‑prioritize non‑core services under resource pressure.

Service Degradation : Apply fallback, circuit‑breaker, or local‑logic strategies during overload or failures.

Timeout Control : Set reasonable timeouts based on latency testing to avoid cascading failures.

Monitoring : Track traffic, latency, health, and effectiveness.

Health Checks : Adjust routing weights based on service health metrics.

Call & Dependency Tracing : Visualize upstream/downstream dependencies for debugging.

Security : Enforce IP white‑listing, authentication, and signature verification.

SLA Assurance : Implement caching, flow‑control, tiered timeouts, and critical‑path monitoring.

Beyond governance, aspects such as service registration, release approval, deprecation notifications, and automatic discovery are also explored to establish best practices for the organization’s service ecosystem.

Outlook The sales architecture service‑oriented transformation is ongoing; future work will further refine service governance, documentation, monitoring, health detection, and SLA mechanisms.

For more articles, click "Read Original".