AiFanFan Communication System Refactoring: Challenges, Design, and Implementation

AiFanFan Communication is an online consulting tool that connects visitors and merchants. It was built quickly on top of Baidu Business Bridge, inheriting the latter's complex and outdated architecture.

The product faced numerous pain points: lack of business‑logic knowledge within the team, delayed visitor status detection, incomplete advertising data, unstable services, and low team morale. These issues made it difficult to support new feature development.

Problem Definition and Challenges

Problems were classified into product, architecture, and organization layers. Product‑level issues included unclear direction and mixed role definitions. Architecture‑level issues covered an old Windows‑only C++ client, tangled service modules, data duplication, and reliance on self‑operated middleware (Zookeeper, Nginx, Storm, Solr). Organizational issues involved poor business understanding and misaligned team structures.

Solution Overview

The team decided to combine Domain‑Driven Design (DDD) with a micro‑service architecture to rebuild both product and technical layers.

Product Positioning

The new focus is on pre‑sale visitor reception and advertising scenarios for B2B SaaS customers, explicitly defining “what not to do” (e.g., no post‑sale service, no platform‑level features).

Domain and Module Decomposition

Core domains: Visitor, Customer‑Service, Communication‑Protocol, Session. Supporting domains: Data‑Analysis, Lead, Advertising. Common domains: Account, Security, etc.

Technical Architecture

A five‑layer architecture was designed: UI, gateway, business services, communication protocol, and infrastructure. DDD’s four‑layer model (domain, application, infrastructure, interface) was applied, aligning service boundaries with business domains and ensuring each service owns its data. Eventual consistency and data replication were achieved via publish/subscribe and CDC mechanisms.

Key refactor actions included merging overly fine‑grained services, creating new focused modules (advertising parsing, intelligent reply, lead service), removing shared business libraries, and enforcing API or domain‑event communication instead of shared caches or DB tables.

Protocol Optimization

To improve robustness, the notification module now uses distributed locks and adds a SeqId to packets for ordering. The protocol was simplified to state‑based messages, reducing packet count by ~60%. The client switched from a pure long‑socket connection to an HTTP + socket pull‑push hybrid, allowing it to recover from network issues by actively pulling the latest state.

Middleware Reduction

Self‑operated middleware was phased out: Zookeeper migrated to K8s ConfigMap, Nginx clusters consolidated into BFE, Storm and Solr clusters were decommissioned, and Kafka/Prometheus were handed over to the department’s shared infrastructure.

Client Architecture

The legacy C++ Windows client was replaced with a cross‑platform Electron‑Vue application. A plugin‑based micro‑kernel design enables extensibility via JS‑SDK or WebView plugins. Issues such as high memory usage, GPU‑acceleration on Windows 7, and performance were addressed.

Results

The product architecture was upgraded with clear module boundaries, DDD‑driven rich domain models, and a unified UI across Windows, macOS, and Web.

Customer feedback highlighted improved usability, faster response, and easier lead capture.

Development efficiency increased: the team size shrank from 12 to 7, service count reduced by over 15, code maintainability improved, and system stability reached 99.99% uptime.

Future work includes further cloud‑native evolution, adopting a service mesh, expanding capacity testing, and adding more intelligent features.

{
    "version":"0.0.1",
    "id":"demo-name",
    "name":"Component Name",
    "viewUrl":"",
    "target":"toolbar",
    "dependent": {
        "method": [],
        "version":"1.0.6"
    }
}