How Domain‑Driven Design Tames Complex Business Logic and Boosts Architectural Flexibility

Background

In recent years the Tongtian Tower platform has rapidly built business capabilities and refined its architecture to meet growing demand for high availability and capacity. While the platform now supports most activities and channel constructions for the main site, new requirements increasingly involve personalized, non‑standard data sources and services, sometimes even outside JD's retail ecosystem. To address the rising complexity, the team launched the "Tongtian Tower Blocks" project, a technology‑driven solution based on an open front‑end SDK, back‑end data sources, a flexible canvas, and rapid deployment to any third‑party IT environment, aligning with JD's internationalization and PaaS strategy.

Although the project has achieved initial success, handling extremely complex block business logic and unpredictable changes remains a major challenge, prompting a higher‑level view of the problem and a search for a solution that can manage complexity, scale, and resilience. Domain‑Driven Design (DDD) naturally emerged as the answer.

DDD Value

Eric Evans' seminal book *Domain‑Driven Design – Tackling Complexity in the Heart of Software* emphasizes the importance of a ubiquitous language and provides a comprehensive methodology from strategic to tactical design. By unifying the domain model and design around a common language, DDD separates business concerns from technical concerns, keeping the domain layer consistent and maintainable. Tactical patterns help create clear, cohesive, and extensible code.

Although DDD is not new, it gained renewed attention with the micro‑services wave, which highlighted its value for managing complexity. This article focuses on DDD’s theoretical and conceptual benefits, inviting discussion and feedback.

Understanding Complexity

Complexity stems mainly from requirements, which can be divided into business and technical demands. Business complexity grows with the scale and hierarchy of requirements, while technical complexity arises from quality attributes such as security, performance, concurrency, high availability, and scalability. Mixing business and technical complexity leads to unmanageable systems.

DDD’s core idea is to keep business logic and technical implementation separate, ensuring that business rules remain stable regardless of technology choices.

Strategic Design

Strategic design starts with close collaboration between domain experts and developers to analyze events, extract knowledge, and define a clear problem domain. A ubiquitous language is established, bounded contexts are identified, and a context map outlines relationships between contexts. This decomposition turns a large, monolithic problem into smaller, cohesive sub‑domains.

Bounded contexts act like cells with walls that protect the internal model, ensuring consistency and stability. They also define team boundaries, improve collaboration, and guide micro‑service boundaries.

Domain logic layer defines clear business boundaries and reduces overall system complexity. Team collaboration layer clarifies team responsibilities and aligns with Conway’s law. Technical architecture layer defines integration points and supports independent deployment of micro‑services.

Autonomous Context Characteristics

Minimal completeness : each context provides all functionality needed for its business value without external dependencies.

Self‑fulfillment : the context decides internally which responsibilities to perform.

Stable space : internal changes do not affect external consumers, adhering to the Open‑Closed Principle.

Independent evolution : external interfaces remain stable, allowing the context to evolve without breaking dependents.

Combining these traits ensures that bounded contexts can absorb change with minimal impact.

Context Mapping

Beyond defining bounded contexts, context mapping describes how they collaborate. Eric Evans identifies nine mapping patterns, such as Open Host Service and Anti‑Corruption Layer, which guide integration strategies and micro‑service design.

Architectural Styles

DDD does not prescribe a specific architecture; any style that separates concerns works. Common DDD‑compatible architectures include:

Layered Architecture : separates presentation, application, domain, and infrastructure layers.

Hexagonal (Ports‑and‑Adapters) Architecture : isolates the core domain behind ports, allowing interchangeable adapters for UI, databases, messaging, etc.

Clean Architecture : concentric circles (Entities, Use Cases, Interface Adapters, Frameworks) enforce dependency direction inward.

These architectures emphasize the boundary between business logic and technical implementation.

Layered Architecture Details

Presentation Layer handles UI rendering and user commands without business logic.

Application Layer acts as a façade exposing use‑case services and orchestrates domain operations while handling cross‑cutting concerns (transactions, logging, security).

Domain Layer contains entities, value objects, domain services, and aggregates that model core business concepts.

Infrastructure Layer provides technical capabilities such as persistence, messaging, and external system integration.

Clean Architecture

Entities sit at the core, surrounded by use‑case interactor classes, then interface adapters, and finally frameworks/drivers. Dependencies only point inward, keeping the core independent of external details.

Hexagonal Architecture

Also known as Ports‑and‑Adapters, it divides the system into an inner hexagon (business logic) and outer adapters (UI, DB, messaging). Driving adapters depend on ports, while driven adapters are injected via dependency inversion.

CQRS (Command‑Query Responsibility Segregation)

CQRS separates read (query) models from write (command) models, allowing independent scaling, performance tuning, and security. Combined with DDD, read and write sides can be modeled separately, with eventual consistency achieved via domain events.

DDD Tactical Design

Tactical design applies the DDD building blocks within a bounded context:

Entity : an object with a unique identity.

Value Object : immutable objects representing concepts without identity.

Aggregate : a cluster of entities and value objects treated as a single unit with a root entity.

Domain Service : stateless operations that don’t naturally belong to an entity or value object.

Repository : abstracts persistence for aggregates.

Domain Event : captures significant state changes for eventual consistency.

Factory : encapsulates complex creation logic.

Module : groups related concepts with high cohesion and low coupling.

Domain Primitive

Domain primitives are enriched value objects that encapsulate validation and behavior, turning implicit concepts (e.g., integer codes) into explicit, self‑validating types such as ActivityType, Money, Percentage, etc.

Conclusion

DDD is a modeling methodology rather than a framework, which makes its adoption challenging. Successful practice requires domain experts and technical teams to set aside their biases, focus on the problem domain, and collaborate using a ubiquitous language. The Tongtian Tower backend team has strong experience in high‑concurrency systems but is just beginning its DDD journey, planning to share further practical insights.