How Keep Revamped Its E‑Commerce Supply Chain with DDD and EventStore

Any business architecture inevitably accumulates historical issues; selecting new, appropriate architectural ideas to refactor it is a core skill for architects. This article shares Keep’s practical use of Domain‑Driven Design (DDD) to transform its e‑commerce supply‑chain system, originally featured on InfoQ.

The supply‑chain system (also known as an inventory management system) handles the dynamic flow of procurement → inbound → sales, managing warehouse stock and acting as a bridge in the e‑commerce ecosystem. Legacy systems Skynet and ERP became heavy and problematic over years of rapid iteration, leading to unclear system boundaries, tangled architecture, inaccurate inventory, and inability to meet new business requirements.

Key Problems of the Legacy System

Unclear system boundaries

Chaotic architecture with unclear layering

Blurry use cases causing unclear code boundaries and transactions

Unclear responsibilities and interfaces across layers, leading to dependency cycles

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

New business demands such as automated store inventory allocation, intelligent procurement, inventory accuracy guarantees, fulfillment rate guarantees, and improved operational efficiency

These issues made incremental fixes impossible, prompting a full redesign of the supply‑chain system.

Refactoring Approach

The redesign follows three major steps:

Analyze inventory business scenarios

Identify bounded contexts

Model the inventory domain

Inventory model definitions include:

Occupied inventory: sold but not yet shipped

Available inventory: physical stock minus occupied inventory

Physical inventory: actual stock in the warehouse

In‑transit inventory: purchased but not yet received

Frozen inventory: reserved for promotions or inter‑warehouse transfers

DDD architectural choices emphasize:

Separating domain and non‑domain models using a hexagonal architecture

Ensuring core domain model stability via dependency inversion and layered design

Preventing custom query pollution of the domain model by applying CQRS to separate commands and queries

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

Implementation Details

The final architecture adopts the COLA pattern and an EventStore for event sourcing. Domain events are published and subscribed as follows:

Event subscription groups are registered, and specific events are declared within those groups.

Continuous integration is supported by comprehensive unit testing:

Domain model unit tests (Domain tests)

Command execution tests for core business interfaces (CmdExe tests)

Mockito for mocking dependencies and data

Test data generation within test code

H2 in‑memory database for isolated tests

Minimal reliance on external middleware (e.g., Dubbo, Kafka) by mocking when needed

Automatic test execution on git push via CI pipelines

Outcomes

The refactor delivered five major benefits:

Accurate inventory, eliminating warehouse stock discrepancies and providing a reliable baseline for sales inventory

Facilitated functional extensions, such as rapid integration with financial systems

Improved issue localization thanks to clear code structure and traceable inventory changes

Created a reusable EventStore component for broader adoption within Keep’s e‑commerce platform

Established mature DDD best practices to guide future redesigns of inventory and after‑sale systems

Overall, the experience demonstrates how DDD complements microservices by defining clear business boundaries, making it an effective strategy for service decomposition.