How DDD Transforms Complex Store Systems: From Monolith to Scalable Microservices

Introduction

In the era of digital transformation driven by the industrial internet, increasingly complex business requirements demand new software architectures; Domain‑Driven Design (DDD) re‑emerges as a solution to address boundary chaos, architectural redundancy, and low development efficiency.

System Background

1.1 System Overview Daily Fresh is a community‑retail online supermarket that divides its business into people, goods, warehouse, distribution and store. The store is a core scenario responsible for order fulfillment and frontline efficiency.

The store operation system manages inbound, outbound and internal flow of goods, linking order fulfillment and procurement processes.

System Definition

Store System = Store Operations (personnel + machine) + Store Strategy (in‑store + inter‑store)

1.2 Store 1.0

Launched in 2015, Store 1.0 shared a single backend framework with the central warehouse, resulting in tight coupling, limited performance, high expansion cost and heavy operational overhead.

Key Issues

Performance Interference : Single‑service capacity limits and mutual impact between warehouse and store operations.

Expansion Cost : Non‑standard components and manual deployment caused weeks of effort for each new store.

1.3 Store 2.0

In late 2018, rapid business growth required a decoupled architecture. Store 2.0 introduced micro‑services, independent databases, Spring Cloud, Redis, RocketMQ and Elastic Job, while still sharing some core data tables.

Technical Architecture

Spring Cloud backend, MySQL sharding, Redis cache/lock, RocketMQ for async decoupling, Elastic Job for scheduled tasks.

Exposed Problems

Data Coupling : Micro‑services still share a common database, limiting true isolation.

Performance Bottlenecks : Over‑splitting, uneven load, large tables (up to 30 M rows) cause slow queries and task contention.

Iteration Efficiency : Repeated feature duplication across services inflates maintenance cost.

1.4 Store 3.0

Started in 2020 to support user experience, order volume growth and platformization. Store 3.0 adopts a service‑oriented DDD architecture, prepares for automation and long‑term scalability.

Technical Architecture

Spring Boot, Dubbo for RPC, MySQL sharding‑sphere, ES‑based CrateDB for complex queries, Redis, RocketMQ, Elastic Job. The code follows the classic DDD four‑layer model (interface, application, domain, infrastructure).

II. Domain Design

DDD emphasizes aligning technical architecture with business boundaries. It advocates moving from data‑centric MVC to domain‑centric layers, distinguishing entities, value objects, aggregates, domain services and events.

Strategic Design

Define system boundaries, map business domains to micro‑services, and decide service granularity based on team size.

Tactical Design

Identify core processes, entities, aggregates, actions, domain services and events. Example: a “Lock Stock” process includes workflow steps, entity identification, aggregate root definition, action methods (approve, unlock, cancel), domain services for cross‑domain coordination, and asynchronous events for decoupling.

public interface StringWebEnum { String getCode(); String getDesc(); }

public interface IntWebEnum { int getCode(); String getDesc(); }

III. Technical Implementation

Code Framework

Four‑layer DDD structure:

Interface layer (API, RPC)

Application layer (controllers, DTOs, factories, tasks, MQ listeners)

Domain layer (aggregates, entities, value objects, domain services, repositories)

Infrastructure layer (adapters, repository implementations, MQ producers, utilities)

Layer Rules

Domain layer contains business logic only; infrastructure provides persistence and external adapters; application assembles inputs/outputs and invokes domain services.

Common Pitfalls

Domain entities must not call repositories directly.

Repositories should only handle their own aggregate.

Distinguish domain services from application services.

Use adapters to isolate external dependencies.

Advantages of DDD

Minimal impact on unchanged data models.

Dependency inversion across layers.

Improved code readability and maintainability.

Scalable micro‑service decomposition.

Practical Tips

Prohibit setters in domain objects; enforce changes via methods.

Use clear naming conventions (Request/Response suffixes).

Abstract enums for front‑end consumption.

IV. Team Operations

Successful DDD adoption requires a reference implementation, clear conventions, multi‑stage code reviews, and continuous knowledge sharing within the team.