Understanding Domain-Driven Design: Value, Process, and Architectural Practices

In recent years the Tongtian Tower platform has rapidly built business capabilities and refined its architecture to meet increasing demand for capacity, high availability, and other technical requirements. While the platform now supports most activities and channel constructions for the group’s main site, new demands are shifting toward highly personalized, non‑standard data sources and services, many of which lie outside JD’s retail ecosystem. To cope with this growing complexity, the team launched a technology‑driven project called Tongtian Tower Blocks, which provides an open front‑end SDK, flexible back‑end data sources, and a powerful canvas that can be quickly deployed to any third‑party IT environment.

Facing increasingly complex business logic and unpredictable changes, the team sought a solution that decouples business from underlying technical foundations. The concept of Domain‑Driven Design (DDD) emerged as a promising approach.

In 2004 Eric Evans published the influential book *Domain‑Driven Design – Tackling Complexity in the Heart of Software*, emphasizing the importance of a ubiquitous language and presenting both strategic and tactical design methods. By unifying the domain model across all participants, DDD separates business concerns from technical concerns, leading to a layered architecture that isolates complexity.

Although DDD has existed for over a decade, it gained renewed attention with the rise of micro‑services, which naturally complement DDD’s emphasis on bounded contexts and clear boundaries.

DDD Value

Complexity originates from both business and technical requirements. Business complexity grows with the number and hierarchy of requirements, while technical complexity stems from quality demands such as security, performance, high concurrency, high availability, and scalability. DDD’s core idea is to keep business logic orthogonal to technical implementation, ensuring that business rules remain stable regardless of the underlying technology.

Strategic design in DDD involves close collaboration between domain experts and developers to extract a clear problem domain, define bounded contexts, and map relationships, thereby breaking a large system into smaller, cohesive sub‑domains. Tactical design provides a rich set of building blocks—entities, value objects, aggregates, domain services, repositories, factories, and modules—to model each sub‑domain with high cohesion and low coupling.

Layered Architecture

DDD introduces a four‑layer architecture: Presentation (UI) Layer, Application Layer, Domain Layer, and Infrastructure Layer. The Application Layer acts as a façade exposing use‑case services and mediating between UI and Domain, while the Domain Layer contains the core business model (entities, value objects, domain services). Infrastructure provides technical capabilities such as persistence and external APIs.

Hexagonal Architecture

Also known as the Ports‑and‑Adapters architecture, it separates the core domain (inside the hexagon) from external drivers (outside). Ports define contracts; adapters implement those contracts for specific technologies (e.g., REST, messaging, databases). This ensures that business logic stays independent of technical details.

CQRS (Command‑Query Responsibility Segregation)

CQRS splits read and write models, allowing independent optimization of queries and commands. Combined with DDD, it enables high‑performance, scalable systems where the write side updates domain aggregates and publishes events, while the read side maintains denormalized views.

Domain Primitives and Domain‑Specific Objects

DDD encourages turning implicit concepts (e.g., activity type codes) into explicit value objects or domain primitives that encapsulate validation and behavior. This reduces hidden state, improves type safety, and makes the model expressive.

Strategic Design Process

1. Problem‑Domain Extraction – domain experts and developers collaborate to model the problem space using a ubiquitous language. 2. Identify Bounded Contexts – partition the model into cohesive contexts, each with its own language and boundaries. 3. Context Mapping – define relationships between contexts (e.g., Open Host Service, Anti‑Corruption Layer) to guide integration and micro‑service boundaries.

Tactical Design Process

Within each bounded context, apply DDD building blocks: entities, value objects, aggregates, domain services, repositories, factories, and modules. Use patterns such as immutable value objects, rich domain models, and event‑driven communication to keep the model robust and testable.

Integration with Micro‑services

Bounded contexts naturally map to micro‑services, allowing independent deployment, scaling, and evolution. DDD provides the strategic guidance to define service boundaries, while micro‑service characteristics (loose coupling, independent lifecycle) reinforce DDD’s architectural goals.

Challenges and Practical Considerations

DDD is not a framework but a methodology; its adoption requires deep collaboration between domain experts and engineers, a willingness to shift thinking from solution‑centric to problem‑centric, and disciplined modeling practices. The Tongtian Tower team acknowledges the steep learning curve and plans to share concrete implementation experiences in future articles.

References

[1] *Domain‑Driven Design* by Eric Evans – https://book.douban.com/subject/5344973/ [2] “When the Middle‑Platform Meets DDD” – https://www.infoq.cn/article/7QgXyp4Jh3-5Pk6LydWw [3] Zhang Yi’s series – http://zhangyi.xyz