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

Any business architecture inevitably accumulates historical issues; architects must refactor with appropriate new architectural ideas.

The focus here is a supply‑chain (inventory) system that manages the purchase → stock → sales chain, serving as a bridge in e‑commerce by handling order shipping, returns, purchase replenishment, inter‑warehouse transfers, and special inbound/outbound processes. Legacy Skynet and ERP systems, built when Keep entered e‑commerce, grew heavy over years, causing increasing operational problems and hindering business growth due to lack of systematic planning and code standards.

Main problems identified:

Unclear system boundaries.

Messy architecture with unclear internal layers.

Inventory issues:

Inaccurate inventory leading to frequent over‑sell or under‑sell.

Non‑standard inventory change logs with unclear context, making root‑cause analysis difficult.

Inventory and change logs cannot self‑verify correctness.

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

To address these pressures, the refactoring plan consists of three major categories:

Clarify inventory business scenarios.

Define bounded contexts.

Define inventory models (occupied, available, physical, in‑transit, frozen).

After clarification, a DDD‑based architecture was chosen, emphasizing:

Mapping domain and non‑domain models via Hexagonal architecture.

Ensuring core domain model stability using Dependency Inversion; the domain layer does not depend on other layers, while lower services depend on higher‑level interfaces.

Preventing custom queries from corrupting the domain model by introducing CQRS to separate command and query models.

Preventing cross‑bounded‑context interactions from corrupting the domain model through an anti‑corruption layer (ACL) that maps warehouse information to value objects.

The final implementation adopts a COLA (Clean‑Architecture) style and uses EventStore for event sourcing. The data flow includes publishing domain events and handling exceptions (see diagram).

Event publishing code and subscription setup are illustrated in the following images:

Testing practices include unit tests for core domain models and command execution, using Mockito for mocking, H2 in‑memory database to avoid side effects, minimizing reliance on external middleware, and triggering CI‑based automated tests on each push.

Key benefits achieved:

Accurate inventory, eliminating over/under‑sell and providing a reliable baseline for sales inventory.

Easy functional extensions, such as rapid integration with finance systems.

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

Reusable EventStore component promoted across Keep’s e‑commerce services.

Mature DDD best practices established for future inventory and after‑sale system refactorings.

The experience shows that DDD naturally complements microservices by defining clear business model boundaries, while microservices handle the decomposition of monoliths into independent services.