Why Simplicity Drives Service‑Oriented Architecture: Lessons from a Four‑Year Refactor

In early 2014 the author decided to rebuild a bloated system, driven by a strong desire for simplicity after the codebase became clogged with complexity.

Large deployment packages (hundreds of megabytes) caused repeated bottlenecks, prompting the author to decompose the monolith into smaller, manageable services, a natural human approach to handling complexity.

While MVC dominated the web era, the rise of mobile internet led the author to seek a more suitable, multi‑endpoint service abstraction, eventually aligning with Service‑Oriented Architecture (SOA) rather than heavyweight ESB/WS solutions.

The design principle "simplicity" guided the creation of a lightweight, standardized, and abstracted service framework, balancing open‑source flexibility with the need to avoid unnecessary bloat.

Services were split by domain boundaries into independent processes, mirroring OS concepts where services act as processes and threads as business execution units.

The framework defines three service layers: Framework Service, Base Service, and Business Service, each composed of Timer, Initor, Destoryer, SB_Module, SA_Module, and Services components, forming a highly standardized, plug‑in architecture.

Naming conventions enforce uniqueness and execution order, similar to Linux run‑level scripts, ensuring deterministic service startup.

The SessionContext carries thread‑level state, including business session objects, request/response JSON, component contexts, and database transaction data, while the framework provides unified logging, security interception, and data adapters for relational and in‑memory databases.

Service discovery (KingWorks‑RDC) acts like DNS for services, decoupling callers from providers, while the micro‑gateway (KingWorks‑MSG) offers both dynamic and static routing, reducing overhead for stable services.

RDC periodically updates service information and can push change notifications, enabling real‑time updates and supporting hybrid‑cloud scenarios with separate internal and external endpoints.

Automation tools (KingWorks‑OPS) built on a C/S task scheduler (Python‑based OPS‑Agent) provide centralized configuration, monitoring, alerting, and execution for all services.

The team, called DEV‑TEAM, consists of a lead and 2‑3 members, split into front‑end (Android, iOS, H5) and back‑end groups, each handling multiple projects under the unified service‑oriented philosophy.

Ultimately, the four‑year practice demonstrates that simplicity is not naïve minimalism but a disciplined, thoughtful approach that balances freedom with necessary constraints, enabling efficient, scalable backend systems.