How Domain‑Driven Design Can Tame Complex Business Logic in High‑Scale Systems

In recent years the Tongtian Tower platform has rapidly built business capabilities and refined its architecture to meet growing demand, high availability, and other technical requirements. The platform now supports most activities and channel constructions for the group’s main site, but new requirements increasingly involve personalized, non‑standard data sources and services, sometimes even outside JD’s retail system. To address the rising complexity and to stay innovative, the team launched a technology‑driven project called Tongtian Tower "Blocks" (积木), which provides an open front‑end SDK, flexible back‑end data sources, a powerful canvas, and rapid deployment to any third‑party IT environment, aligning with JD’s internationalization and PaaS strategy.

DDD Value

Eric Evans’s 2004 book *Domain‑Driven Design – Tackling Complexity in the Heart of Software* emphasizes the importance of a ubiquitous language and presents a methodology from strategic to tactical design. By unifying the domain model, DDD separates business logic from technical implementation, keeping the domain layer consistent with the model. Tactical patterns help build clear, cohesive, and maintainable code.

Although DDD is not new, it gained renewed attention with the microservices wave, which highlighted its value for handling complex business domains.

Handling Complex Business

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 includes security, performance, concurrency, high availability, and scalability concerns. Mixing business and technical complexity leads to unmanageable systems.

D​DD aims to keep business logic separate from technical implementation, ensuring that business rules remain stable regardless of the underlying technology.

Strategic Design

Strategic design involves close collaboration between domain experts and developers to analyze events, extract knowledge, and define a clear problem domain. This results in a ubiquitous language, bounded contexts, and a system context that outlines external integrations. The domain layer is placed at the core of a layered or hexagonal architecture, protecting it from technical changes.

Key steps include:

Refining the problem domain and avoiding premature solutions.

Using a unified language for communication.

Identifying core, generic, and supporting sub‑domains.

Defining bounded contexts and their relationships.

Bounded contexts act like cells with walls that protect the domain model, ensuring consistency and stability.

Identifying Bounded Contexts

After clarifying business goals, teams map major business processes, derive use cases, and analyze scenarios to extract actors and activities. By aligning these with the ubiquitous language, contexts are identified based on semantic and functional relevance.

Eric Evans describes nine context‑mapping patterns, such as Open Host Service and Anti‑Corruption Layer, which guide how bounded contexts collaborate.

Autonomous Context Characteristics

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

Self‑fulfillment : the context decides what it should do based on its own knowledge.

Stable space : internal changes do not affect the context’s external contract.

Independent evolution : the context can evolve without breaking downstream consumers.

Architectural Design

D​DD does not require a specific architecture; any style that separates business from technical concerns works. Common choices include layered architecture, hexagonal (ports‑and‑adapters) architecture, and clean architecture.

Layered Architecture

The domain layer holds entities, value objects, and domain services. The application layer acts as a façade, exposing use‑case services and orchestrating domain logic. Infrastructure provides persistence, messaging, and other technical capabilities.

Typical layers:

Presentation (UI) Layer : only coordinates with the application layer, no business logic.

Application Layer : façade for use cases, composes domain services, handles cross‑cutting concerns.

Domain Layer : core business concepts, entities, value objects, domain services.

Infrastructure Layer : technical details such as databases, external APIs.

Hexagonal Architecture

Also known as ports‑and‑adapters, it places the business core at the center and surrounds it with adapters for UI, databases, messaging, etc. Communication follows the Dependency Inversion Principle: the core depends on abstract ports, while adapters implement them.

Clean Architecture

Uses concentric circles: Entities → Use Cases → Interface Adapters → Frameworks & Drivers. Dependencies point inward, keeping the core independent of external frameworks.

CQRS (Command‑Query Responsibility Segregation)

CQRS separates read and write models, allowing independent scaling and optimization. Combined with DDD, commands modify aggregates while queries use separate read models, often synchronized via events.

Domain‑Driven Design Tactical Model

Key building blocks:

Entity : an object with a unique identity that persists over time.

Value Object : immutable objects representing concepts without identity; they encapsulate validation and behavior.

Aggregate : a cluster of entities and value objects treated as a single unit with a root entity; it defines transaction boundaries.

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

Repository : abstracts persistence for aggregates, exposing only domain‑relevant methods.

Domain Event : captures significant domain occurrences, enabling eventual consistency and event‑driven architectures.

Factory : encapsulates complex creation logic for aggregates.

Module : groups related domain concepts, promoting low coupling and high cohesion.

Additional concepts such as Domain Primitives (rich value objects with validation and behavior) help make implicit business rules explicit and reduce duplicated code.

Conclusion

D​DD is not a framework but a methodology for tackling complex business problems. Its adoption requires deep collaboration between domain experts and developers, a shift from feature‑first thinking to business‑value‑first modeling, and disciplined architectural choices. The Tongtian Tower backend team, with extensive experience in high‑concurrency systems, is beginning its DDD journey and plans to share practical lessons in future articles.

References:

Domain‑Driven Design book

When the middle platform meets DDD

Zhang Yi series