Designing a Flexible Retail Product System with DDD and Decompose‑Orchestrate Architecture

Background

Retail product systems must support a wide range of business processes—catalog browsing, order creation, inventory management, logistics, settlement and after‑sale services—while handling large transaction volumes and diverse industry requirements.

Key Challenges

Multi‑industry attribute variance : Supermarkets, hotels, education and fresh‑food sectors each define distinct product attributes.

End‑to‑end business chain : The system must coordinate procurement, sales, returns, logistics and settlement across multiple bounded domains.

Dual B‑side / C‑side requirements : Enterprises need bulk operations and inventory control, whereas consumers expect smooth browsing, purchasing and payment flows.

Architectural Principles ("Dao")

Deep business understanding through Domain‑Driven Design (DDD) to capture core concepts and keep architecture aligned with the domain.

Evolutionary and extensible design that can adapt to changing requirements and emerging technologies.

Business‑driven modeling that maps domain entities directly onto system components.

Technical Techniques ("Shu")

Layered and modular decomposition to separate responsibilities and avoid code duplication.

Application of SOLID principles (SRP, OCP, DIP) to achieve loose coupling and high extensibility.

Deliberate technology selection (programming language, middleware, database) to meet performance, scalability and productivity goals.

Domain Decomposition Strategy

Bounded Contexts & "Decompose + Orchestrate"

The product domain is split into autonomous bounded contexts such as core product, inventory, category and attribute. Each context is classified as core, generic or supporting, reducing horizontal coupling.

Complex product types (bundles, virtual, pre‑sale, etc.) are handled by breaking business logic into small, single‑purpose components (decompose) and chaining them via a responsibility‑chain pattern (orchestrate). This follows the open‑closed principle and enables component reuse across different flows.

Abstract Domain Model

A unified domain model captures essential business concepts independent of implementation language. Core attributes (name, category, barcode, product type, unit) are stored in the main product entity, while volatile or industry‑specific attributes (origin, class time, etc.) are represented as custom attributes bound to a template. Templates are identified by a numeric field_id, similar to Protocol Buffers, reducing storage overhead.

DDD Layered Architecture

The system follows a four‑layer DDD structure:

Interface layer : Defines API contracts, request/response DTOs and exposes services to external callers.

Application layer : Orchestrates use‑cases, triggers messages, schedules jobs and composes domain services.

Domain layer : Contains entities, value objects, aggregates, domain services and repository interfaces. Business rules reside here.

Infrastructure layer : Implements technical concerns such as MySQL access, caching, RPC clients, message queues and middleware configuration.

Data Model Separation

Three distinct data‑model types enforce clear responsibilities:

DO (Database Object) : Direct mapping to relational tables; accessed via Repository interfaces.

VO (Domain Model Object) : Represents business concepts after converting from DO; used within the domain layer.

DTO (Data Transfer Object) : Optimized for external communication (REST, RPC, messages); constructed from VO in the application layer.

This separation minimizes coupling, simplifies evolution, and clarifies the boundary between business logic and technical infrastructure.

Implementation Highlights

Component configuration for front‑end rendering (input types, dropdowns, radio buttons) is stored in component_config and paired with label and rules (required, length, regex, read‑only, visibility).

When creating a product, the system selects the appropriate template, loads its custom attributes, validates input against rules, and persists core fields in the main product table while storing custom fields as field_id ‑value pairs in a generic attribute table.

Responsibility‑chain orchestration allows new product types (e.g., combo products) to be introduced by adding two new components—pre‑condition check and detail recording—without touching existing logic.

Conclusion

By applying DDD, decomposing complex flows into reusable components, abstracting a unified domain model, and enforcing a strict layered architecture with DO/VO/DTO separation, a retail product system can simultaneously satisfy diverse B‑side bulk‑operation needs and C‑side consumer experiences while remaining adaptable to future business growth.