Evolution of JD Advertising System Architecture: From Monolithic Code to Domain‑Driven Design

Since last year JD's advertising delivery system has undergone a major architecture upgrade based on Domain‑Driven Design (DDD). The series of articles aims to explain the motivations, design decisions, and incremental improvements that led to the new architecture.

What makes a good code architecture? It should be easy to extend, enable code reuse, preserve logical knowledge, and run stably. These goals drive the design of the successive generations.

First Generation: No Architecture

The initial design was a flat, database‑centric codebase where data queries and business logic were interwoven, which worked for simple early scenarios but quickly became problematic as features grew.

Problems included patch‑style development with many if‑else branches, repeated data queries, and deep nesting that made the code hard to understand and maintain.

Second Generation: Context Mechanism

To eliminate duplicate queries, a context object was introduced to load all required data at the start of a request and share it throughout the workflow.

While the context solved repeated queries and enabled batch operations, it also introduced heavy, duplicated context‑building code and did not fully address the complexity of multi‑scenario business flows.

Third Generation: Separation of Data and Business Models (Aggregates)

Recognizing that business rules vary across scenarios while the underlying data model remains stable, the design adopted DDD aggregates. An aggregate groups closely related entities under a single root, exposing a repository for data access.

This abstraction moved most query and assembly logic into the repository layer, dramatically reducing context‑building code, eliminating duplicate implementations, and making the data model easier to understand and maintain.

Fourth Generation: Domain Capability Splitting and Orchestration

The system further decomposes complex business processes into orthogonal "capability nodes". Each node defines a façade and one‑to‑many capability instances (e.g., different bidding strategies). An orchestration layer routes requests to the appropriate instance and composes nodes into complete services.

A standard business‑process executor template enforces a fixed sequence (validation → context init → business logic → persistence → events), allowing the orchestration framework to automatically re‑assemble fragmented logic while preserving data sharing and reducing duplicated queries.

Summary

The architectural evolution—from a monolithic codebase to context‑based designs, then to DDD aggregates, and finally to capability‑oriented orchestration—demonstrates how JD achieved extensibility, code reuse, stability, and easier knowledge transfer in its advertising platform.