How Alibaba Entertainment Uses Domain‑Driven Design to Tackle Complex Systems

What Is Domain‑Driven Design?

Domain‑Driven Design (DDD) was introduced in 2004 by Eric Evans in his book Domain‑Driven Design: Tackling Complexity in the Heart of Software . After fifteen years, DDD has become popular in China’s internet circles, promising solutions to the problems of traditional layered architectures.

Why DDD Became a Must‑Have

Software systems solve specific real‑world problems. When faced with complex domains, DDD provides a methodology to decompose problems, define sub‑systems, and guide their implementation, helping large‑scale systems overcome architectural challenges.

Strategic and Tactical Design

Evans splits system design into strategic and tactical layers. The strategic layer introduces concepts such as domain, sub‑domain, and bounded context, while the tactical layer defines entities, value objects, domain services, events, aggregates, factories, and repositories.

Problems with Traditional Layered Architecture

Many micro‑services adopt a layered structure where business logic resides in Service and Manager layers, using DO, DTO, BO, VO for data transfer. In practice, developers often blur the distinction between Service and Manager, leading to duplicated responsibilities, excessive third‑party dependencies, and reduced code readability.

Alibaba Entertainment’s DDD Practice

The key is to identify business models that evolve with the product. Alibaba’s efficiency platform provides annotations for domain elements and an SDK to automate model collection, evaluation, and code generation.

Step 1: Developers annotate business code according to domain design principles.

Step 2: The platform scans the project and gathers the domain model.

Step 3: Developers refine the model in the platform and regenerate code that conforms to DDD standards.

Model Lifecycle

For existing applications, developers add domain annotations to classes, attributes, and methods. If the system is data‑model driven, the data model can be transformed into a domain model via the platform.

Health‑Check and Scaffold Generation

After model construction, the platform validates the model against DDD rules, scoring it before allowing scaffold generation. The generated scaffold follows the hexagonal (ports‑and‑adapters) architecture, isolating core domain logic from external dependencies such as other micro‑services, HTTP, databases, caches, and message queues.

Four‑Layer Hexagonal Architecture

User Interface Layer – handles presentation logic.

Application Layer – orchestrates use‑case workflows without implementing business details.

Domain Layer – implements core business logic.

Infrastructure Layer – provides concrete implementations of external dependencies.

Traditional vs. Dependency‑Inverted Layering

Traditional layering allows all upper layers to depend directly on the infrastructure layer, which often leads to rule violations. The dependency‑inverted approach enforces that only the infrastructure layer may depend on the others, and upper layers must use inversion‑of‑control to access infrastructure services, improving testability and stability.

Conclusion

While classic three‑ or multi‑layer architectures are common, they often fall short in isolation. Selecting an architecture that matches business characteristics can extend project lifespan, reduce refactoring frequency, and lower labor costs.