Building a Flexible Retail Product System with DDD and Decompose‑Orchestrate

1. Introduction

In today’s digital era, retail is rapidly evolving, and consumer shopping behavior and expectations have changed dramatically. To meet growing demand, retail enterprises must build highly flexible and robust product systems.

This article delves into the underlying logic of retail product systems, focusing on Domain‑Driven Design (DDD) and complex business system architecture experience, revealing their application and value in retail.

2. Challenges Faced

The product system permeates the entire business flow—scanning at checkout, adding to cart, ordering, product detail pages, mini‑programs, marketing activities, inventory, supply chain, after‑sales, fulfillment, etc. Because the product system is foundational and core, its challenges are increasingly complex.

Challenge 1: Integrating Diverse Industry Demands

Retail spans many sectors, each with distinct product management needs—from supermarkets and convenience stores to hotels, education, and fresh food. Product attributes differ greatly across industries.

Challenge 2: Supporting Complex Business Chains

The product system must support every link from procurement to sales to returns, involving supply chain, orders, logistics, settlement, after‑sales, and multiple business domains.

Challenge 3: Dual B‑Side and C‑Side Requirements

The system must provide powerful product management tools for merchants (B‑side) while delivering a smooth browsing and purchasing experience for consumers (C‑side). Balancing bulk operations, inventory management, and user‑centric features requires careful design.

3. Architecture “Dao” and “Shu”

Architecture involves not only technical decisions but also deep business understanding and foresight of system evolution.

3.1 The “Dao” of Architecture

The “Dao” emphasizes overall planning, design, and evolution strategy, including:

Deep business understanding through DDD to capture core concepts and domain models.

Evolvability and extensibility to adapt to changing business and technology.

Business‑driven design that maps domain concepts to system architecture.

3.2 The “Shu” of Architecture

The “Shu” focuses on concrete technical choices, covering:

Layering and modularization to separate responsibilities and reduce code duplication.

Design principles and patterns such as Single Responsibility, Open‑Closed, Dependency Inversion.

Technology stack selection (programming languages, middleware, databases) that impacts performance and scalability.

4. Retail Product Architecture

4.1 “Divide‑and‑Conquer” Strategy

Retail products involve many modules—SPU, SKU, front‑end categories, back‑end categories, brands, inventory, standard items, attributes, templates, etc.—with intricate horizontal relationships. As user scale grows, vertical domain construction adds complexity.

To manage this, we adopt a divide‑and‑conquer approach, introducing bounded contexts that split the large product domain into autonomous sub‑domains such as core product, inventory, category, and attributes. Each sub‑domain focuses on its own concerns, reducing coupling.

Different product types (bundled, temporary, virtual, pre‑sale) each have unique rules. Building each type in isolation creates “silos” and duplicate logic. Consolidating them in a single flow leads to extensive if / else branches, harming code cleanliness.

We solve this with a decompose + orchestrate strategy, using common design patterns to build an efficient, maintainable system. Decompose: Break complex business logic into small components, each handling a single function, aligning with the Single Responsibility Principle. Orchestrate: Use a responsibility‑chain to select and compose components, enabling reuse across different business flows while respecting the Open‑Closed Principle.

How to decompose and orchestrate? What tools can be used out‑of‑the‑box?

We recommend “matrix thinking”: map each business process vertically (scenarios) and horizontally (actions) to create a matrix that clarifies commonalities and specifics.

After decomposition, standardize business logic into independent components and assemble them in the application layer. For example, adding a new bundled product only requires two new components— Check bundled product preconditions and Record bundled details —which can be quickly composed without affecting other domains.

4.2 Abstract Domain Model

Different industries have vastly different product attributes. Building separate storage structures for each industry is costly and inflexible, while a single monolithic schema struggles with heterogeneous fields and validation rules.

A domain model records the key concepts and vocabulary of a system, showing relationships between main entities and defining their important methods and attributes.

By abstracting business requirements into a domain model, we separate business concerns from technical implementation. The retail product domain model includes a core product entity with stable attributes (name, category, barcode, type, unit) and a set of custom attributes stored via templates for flexible fields like “origin” or “class time”.

Custom attribute configuration includes:

component_config : Front‑end rendering information (input types, dropdowns, etc.).

label : Field title displayed to the user.

rules : Validation rules (required, length, read‑only, visibility, regex, etc.).

When a merchant creates a product, the system selects the appropriate template and binds custom attributes via a field_id. To avoid redundancy (e.g., repeated expiration_data), we borrow the Protocol Buffers idea of assigning numeric identifiers to attributes, dramatically reducing storage overhead.

4.3 DDD Layered Architecture

A robust system adopts a layered architecture, often placing the Domain at the bottom and Infrastructure above it, with repositories bridging the two.

Layers and responsibilities:

Interface Layer : Defines API contracts, request/response structures.

Application Layer : Orchestrates domain services, handles user actions, triggers messages, MQ, and scheduled tasks.

Domain Layer : Core business logic—entities, value objects, aggregates, domain services, repository interfaces.

Infrastructure Layer : Provides technical capabilities (MySQL, cache, RPC, middleware configuration) and implements repository interfaces.

Each layer is isolated by packages; sub‑domains (product, inventory, category) are organized by bounded contexts.

4.4 Data Flow

All system operations ultimately reduce to data manipulation. We separate data models into three categories:

DO (Database Object) : Direct mapping to database tables, handled by repositories.

VO (Domain Model Object) : Business‑oriented objects used within the domain layer.

DTO (Data Transfer Object) : Objects exposed to external clients, possibly transformed for performance or compatibility.

This separation decouples layers, allowing each to focus on its specific responsibilities while maintaining overall system cohesion.

5. Conclusion

In the digital wave of retail, building a highly flexible and reliable product system is urgent. Domain‑Driven Design combined with a divide‑and‑conquer plus orchestration strategy addresses core challenges. The “Dao” emphasizes business understanding and model‑driven design, while the “Shu” applies layering, patterns, and technology choices. From abstract domain models to DDD layered architecture and disciplined data flow, these practices enable a stable, high‑performance retail product system that supports continuous business evolution.