How DDD and Event Sourcing Revamped a Legacy Supply‑Chain System

Any business architecture inevitably accumulates legacy issues; applying fresh, appropriate architectural thinking to refactor it is a core skill for architects.

The subject is the supply‑chain (inventory) system, also known as the procurement‑inbound‑sales system, which manages the dynamic chain of purchasing, warehousing, and sales, serving as a crucial link in e‑commerce. The Skynet and ERP systems act as the core components handling order fulfillment, returns, procurement replenishment, inter‑warehouse transfers, and special inbound/outbound processes.

Both Skynet and ERP are veteran systems built when Keep entered the e‑commerce arena. After years of rapid requirement iteration, they became heavily burdened, leading to numerous operational problems. The legacy supply‑chain system lagged behind business growth and even threatened further development due to a lack of systematic planning and code standards.

Unclear system boundaries

Chaotic architecture with indistinct layering

Vague use cases causing unclear code boundaries and transaction scopes

Unclear responsibilities across layers and interfaces, resulting in dependency confusion and circular dependencies

Inaccurate inventory and unclear inventory‑change context

Frequent over‑selling or under‑selling

Non‑standard inventory change logs, making root‑cause analysis difficult

Inability to verify inventory correctness from logs

New business requirements include automated store inventory allocation, intelligent procurement, inventory accuracy guarantees, fulfillment rate guarantees, and improved operational efficiency.

Because the legacy system could no longer be fixed through patches, a full reconstruction was scheduled.

The refactor plan is organized into three major categories:

Clarify inventory business scenarios

Define bounded contexts

Design the inventory model

Occupied inventory: sold but not yet shipped

Available inventory: physical stock minus occupied inventory

Physical inventory: actual items in the warehouse

In‑transit inventory: purchased but not yet received

Frozen inventory: reserved for flash sales, inter‑warehouse transfers, etc.

After clarifying these aspects, the DDD architectural selection becomes critical.

Map domain and non‑domain models using a hexagonal architecture

Ensure stability of core domain models

Layered design follows the Dependency Inversion Principle: the domain layer does not depend on any other layer, while lower‑level services depend on interfaces provided by higher layers.

Avoid custom query pollution of the domain model

Introduce CQRS to separate command and query models.

Prevent interaction with other bounded contexts from corrupting the domain model

For example, the procurement context uses an anti‑corruption layer (ACL) to map warehouse information from the core inventory context into its own value objects, preserving model integrity.

Final architecture implementation – COLA

Ensure consistency of document statuses across inventory change scenarios

When an inventory change occurs, upper‑level business documents depend on the status changes of lower‑level core warehouse documents (e.g., a purchase inbound order completing triggers the purchase order to become completed).

Solution selection

The team chose an EventStore‑based solution. The data flow is illustrated below.

The yellow part in the diagram represents domain‑event exception handling.

Domain event publishing code (shown as images)

Subscribe to domain events

Register subscription groups

Declare subscribed events within the group.

Balancing efficiency and quality in CI: unit testing

Core domain models are covered by unit tests (Domain tests); business interface scenarios are tested (CmdExe tests). Mockito is used to mock interfaces and data, ensuring reliable test data. Tests run against an H2 in‑memory database to avoid side effects, and external middleware such as Dubbo or Kafka is mocked or avoided. CI triggers automatic unit tests on each push.

Finally, the refactor yielded five major benefits:

Accurate real‑time inventory, fully solving warehouse stock inaccuracy and providing a reliable baseline for sales inventory.

Easy functional extensions, e.g., quick integration with financial systems.

Rapid issue localization thanks to clear code structure and traceable inventory changes.

A reusable EventStore component that can be quickly adopted across Keep’s e‑commerce services.

A mature DDD best‑practice package ready for rollout to other inventory and after‑sale systems.

These results demonstrate that DDD, while often associated with micro‑services, naturally complements them: DDD defines clear business model boundaries, while micro‑services split a monolith into independent services. DDD thus provides an excellent strategy for micro‑service decomposition.