Mastering DDD in Supply Chain: Overcoming Complexity with Strategic Design

Preface

The author, after a short period of practicing DDD in the supply‑chain product domain, encountered many problems, found some answers, and is still exploring others. Invited to share experiences with the supply‑chain service and innovation team, the author now presents these insights to spark further discussion.

Why DDD?

DDD is not only a technical issue but also an execution and implementation challenge. It helps address software complexity by providing a suitable domain model that maps real business, extending OOAD, and offering solutions such as dividing and conquering, separating concerns, layered architecture, and a unified language.

1. What is Software Complexity?

Before starting DDD, we must ask why we need it. Complex software suffers from three main challenges in the Alibaba context: comprehension difficulty, unpredictability, and collaboration difficulty.

1. Comprehension Challenge

Massive requirement scale, numerous business types, and tight coupling across more than 20 industries and various commercial models increase system complexity.

Unclear boundaries among many business systems lead to prolonged discussions on boundary issues.

Mixed functional and non‑functional code (fallback logic, gray‑release logic, retries, etc.) makes the core business code a small fraction of total lines.

2. Unpredictability Challenge

Rapidly changing business environment and rules make early design planning difficult.

Software changes are also unpredictable, creating design challenges.

3. Collaboration Challenge

Requirements often span multiple teams, causing inefficient hand‑offs and low‑efficiency solution generation.

Many team roles and business concepts without a unified language lead to misunderstandings.

2. Why DDD?

Divide and conquer to control scale.

Separate concerns to address comprehension challenges by decoupling domain and storage models.

Layered architecture keeps structure clear, tackling unpredictability.

Unified language mitigates collaboration issues.

3. DDD Core

1. Ubiquitous Language

A shared language is the output of domain knowledge extraction, ensuring all roles (domain experts, product managers, developers) have a consistent understanding of system goals, scope, and functions. Maintaining consistent terminology across documents and code reduces confusion and aligns concepts with implementation.

Defines common terms, reducing conceptual ambiguity.

Facilitates early agreement, eliminating misunderstandings and improving knowledge digestion efficiency.

Connects concepts with code through a unified language.

2. Layered Architecture

Good architecture separates concerns, enabling divide‑and‑conquer and testability. Just as a person juggling many tasks becomes chaotic, code handling many responsibilities must be decomposed into focused parts.

In the product domain, the layered placement of the domain model is illustrated below:

CQRS: Domain model resides below the application layer; commands go through the domain model, queries bypass it.

Tunnel layer: Interfaces with DB and external resources, decoupling domain from persistence (similar to DAO).

External SPI adapters: Hexagonal architecture adapters interact with the model.

3. DDD Elements

Entity : Has an ID, lifecycle, state, attributes, and behavior; external events trigger state changes.

Value Object (VO): Immutable, used to reduce model complexity by grouping related descriptive attributes.

Service : Handles batch operations across multiple entities or cross‑entity actions such as product copy or transfer.

Service responsibilities include entity creation, persistence, and cross‑entity operations. Different layers use different data objects: tunnels use data objects for storage, while entities contain behavior and relationships.

4. Bounded Context

A boundary equals a domain or sub‑domain.

Domain objects have meaning only within their boundary; outside, the meaning may differ.

Language is context‑dependent; responsibilities vary across contexts.

Mapping contexts often uses shared kernels or anti‑corruption layers (ACL). For example, the procurement domain builds an ACL to shield upstream product changes.

4. DDD Implementation

1. Implementation Challenges

Identifying and extracting domain knowledge and reflecting it in model code.

Maintaining an anti‑corruption layer and continuously evolving the model.

Shifting developers’ mindset to think in terms of domains.

2. What Is Domain Knowledge?

Domain knowledge consists of layered, platform‑wide business rules that feed the domain model; merchant‑specific rules should not be pushed down to the model layer.

3. Domain Knowledge Extraction – 5W1H Analysis

Two‑stage analysis: user stories (Who, What, Why) followed by When, Where, How for flow and boundary analysis.

Example: “As a procurement clerk, I need a product with zero inventory to be automatically taken off‑shelf to avoid oversell complaints.”

When/Where/How define trigger conditions, involved domains, and required capabilities.

4. Structured Analysis

Top‑down analysis from the APP layer combined with bottom‑up analysis from the model layer.

Capability sinking keeps the model evolving; standards include reusability and cohesion.

5. Shift in Thinking

During modeling, data design, storage, and messaging are not the focus; business and technical concerns are separated.

5. Supply‑Chain Product Domain Practice

Engineering architecture of the product domain is illustrated below:

Continuously evolve the domain model and keep the README updated; otherwise the APP layer grows while the model layer shrinks, leading to a collapsed domain.