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

Since last year, JD's advertising system has undergone a domain‑driven design (DDD)‑centered architectural upgrade, and this series of articles explains the motivations, design goals, and incremental changes of each generation.

A good code architecture should be easy to extend, reuse, inherit logic, and run stably; these qualities translate into clear separation of business and technical components, orthogonal decomposition of sub‑problems, and minimal coupling.

First generation – No‑architecture code: A flat, database‑centric design that intermixes data queries and business logic, which works for simple early‑stage scenarios but quickly leads to duplicated queries, deep nested conditionals, and tangled logic as business grows.

Second generation – Context mechanism: Introduces a context object that gathers all required data at the start of a request, eliminating repeated queries and enabling batch operations, but brings new pain points such as large, repetitive context construction and still does not address multi‑scenario complexity.

Third generation – Separation of data and business models (Aggregates): Applies DDD aggregates to define a stable data model separate from business rules, moves data‑access logic into repository interfaces, and dramatically reduces context construction and code duplication while improving knowledge transfer.

Fourth generation – Domain capability splitting and orchestration: Decomposes complex business processes into orthogonal capability nodes, each exposing a façade and multiple capability instances; a capability‑orchestration framework then composes these nodes into complete services, handling routing, data sharing, and standard execution steps (validation, context init, processing, persistence, event publishing).

The new architecture thus achieves extensibility, reusability, stability, and easier knowledge transfer, while providing a clear path for future incremental improvements.