Taming Enterprise Application Complexity: Extension Points, CQRS & DDD

Introduction

Frank, a senior technical expert from Alibaba International Technology Division, discusses the challenges of complex enterprise applications and how his team re‑architected their legacy CRM system.

Where Does Complexity Come From?

Poor extensibility – many if‑else branches and lack of a unified extension mechanism.

Procedural code – god‑class ServiceImpl that handles everything.

Unreasonable layering – too many or too few layers increase coupling and overhead.

Lack of standards – inconsistent naming and package organization.

Extension‑Point Design

The new architecture is built around extensible ExtensionPoints combined with metadata, CQRS and DDD. Extension points are declared as interfaces; implementations are annotated and registered at startup.

Identity Recognition

Because the CRM serves multiple business parties and tenants, a two‑dimensional identifier (BizCode, TenantId) is used. An Extension Coordinate (ExtensionPoint, BizCode, TenantId) uniquely identifies an extension implementation.

Extension Registration

All ExtensionPoint interfaces are scanned by a Bootstrap class during Spring startup. Implementations are annotated with BizCode and TenantId; at runtime a TenantContext interceptor selects the appropriate extension.

Domain Modeling and DDD

Domain‑Driven Design is used to make business concepts explicit. By extracting domain objects such as DistributionPolicy and modeling ubiquitous language, the code becomes readable for both developers and domain experts.

SOLID Principles

The team applies the SOLID principles: SRP to avoid god classes, OCP for extensible modules, DIP for decoupling infrastructure (e.g., logging), and ISP for thin interfaces. These guidelines improve code quality and testability.

Layered Design

The application is divided into three logical layers:

App layer – handles input, builds context, validates, and sends messages to the domain.

Domain layer – contains domain services and objects, orchestrates business logic, and calls repositories.

Repository layer – abstracts data sources (MySQL, NoSQL, search, HSF) via a Tunnel concept.

Naming Conventions

Classes and packages follow self‑evident naming rules: client objects end with CO, data objects with DO, and extension implementations with Ext. Clear names reinforce single‑responsibility and improve maintainability.

Overall GTS Architecture

The final architecture integrates extensible extension points, metadata‑driven field extension, CQRS (command/query separation), and DDD to achieve high cohesion, low coupling, and easy scalability.

Programs must be written for people to read, and only incidentally for machines to execute.