Applying Domain-Driven Design and Microservice Architecture in E-commerce Business

The presentation focuses on two aspects: using Domain-Driven Design (DDD) to guide overall architecture and microservice construction (excluding infrastructure), and applying existing software design ecosystems to implement the system. Instead of emphasizing aggregates, entities, and repositories, the emphasis is on boundaries, state, and core design principles such as Open‑Closed, Single Responsibility, Dependency Inversion, Interface Segregation, and the Law of Demeter.

The case study is based on the "Hello Local Life" business, which sells electronic vouchers and covers a full e‑commerce workflow, providing a complex scenario for discussion.

Business Analysis Phase

The goal is to clarify the functions the system must provide by dissecting the problem using the four Ws: Who, Why, What, and How. A diagram (omitted) illustrates the roles and use cases, revealing clear business boundaries—for example, the BD (business development) team handles specific problems with low coupling to other systems.

By aggregating use cases, a "problem space" emerges, aligning the needs of merchants, consumers, BD, suppliers, channel partners, and operations. This space guides team formation and product discussions.

Why Emphasize Problem Space

A problem space represents a class of business issues, helping to organize teams around tightly related functionalities. It influences how a middle‑platform (中台) is built, distinguishing between core capabilities (V1.0) like marketing and transaction services, and higher‑level solutions (V2.0) such as merchant onboarding and user growth.

From Problem Space to System Architecture

Once the problem space is defined, the next step is to plan the system architecture, i.e., microservice construction. Overlapping functionalities (e.g., order placement in both transaction and supplier integration) may be shared across services. The transition from problem space to concrete solutions is described as DDD’s “problem space to solution implementation”.

An event diagram (omitted) demonstrates how business knowledge is abstracted into bounded contexts, which may later be refined into new contexts or boundaries.

After analyzing various business flows, a strategic design diagram (omitted) is produced. Typically, each bounded context maps to a microservice, but flexibility is required; for instance, a core order service might be split into an independent application for stability, or an event hub could be introduced for high‑throughput scenarios.

Software Design Implementation

The talk proposes a template that ensures consistent style and controllable code quality. While seasoned DDD practitioners may find it natural, newcomers may face challenges; thus, the approach aims to simplify onboarding and maintain long‑term stability.

Key Design Guidelines

Coherence as a standard: focus on boundaries rather than strict DDD layers like aggregates and entities.

Layer on demand: a two‑layer split of Dependency (external entry points) and Infrastructure (storage access) acts as a corrosion‑free layer and clarifies system dependencies.

Weaken tactical DDD artifacts: avoid over‑engineering aggregates and entities; instead, use a Spring‑managed singleton as an aggregate, with managers exposing necessary data.

Think about design principles: use interfaces to hide details, keep classes focused, and adhere to Single Responsibility.

Focus on Divide‑and‑Conquer and Abstraction

Divide‑and‑Conquer refers to defining clear boundaries (domain, system, layer, package) to simplify complexity and follow the Single Responsibility Principle. Abstraction can be applied at the process level (extracting core steps into methods) and at the concept level (e.g., representing marketing activities like “add‑on‑purchase”, “full‑reduction”, or “coupon” as a unified interface).