How to Transform a Monolithic Retail Product System into a Flexible, Domain‑Driven Architecture

1. Introduction

With continuous technological advancement, the retail and catering industries are undergoing a comprehensive digital transformation. The smart store concept meets diverse consumer expectations while offering merchants more efficient operational possibilities. Products, as the data carriers of e‑commerce transactions, are crucial. This article explores the need to upgrade the product system architecture to boost innovative business incubation efficiency, improve user experience, and meet the challenges of the digital era.

2. Bottlenecks in the Current Architecture

2.1 High Coupling Between Business Domains

The product domain encompasses categories, product publishing, management, template attributes, cloning, pricing, inventory, procurement, recommendation, and a standard‑product library, serving both store merchants and end users. The current system intertwines these units tightly, as illustrated below.

Creating a temporary product directly manipulates low‑level inventory data; missing categories trigger initialization logic. Complex

特殊

if-else

flows mean a small change can affect many places. As patches accumulate, system entropy rises, leading to rigidity and poor extensibility.

2.2 Low Reusability of Innovative Business

The previous product system for catering was not effectively consolidated, making retail product development costly in time and effort. Reuse is not merely storing data in one place; it requires extracting stable, soulful data models across varied business functions, akin to different human races sharing the same skeletal structure.

2.3 Lack of a Unified Domain Model

The existing architecture is page‑centric: front‑end inputs map directly to database fields, causing instability when business rules change. This violates the principle that lower‑level foundations determine higher‑level structures. A proper domain model emphasizes entities, relationships, and clear business semantics, improving team understanding and collaboration.

3. Architecture Upgrade Plan

3.1 Overall Architecture

The product system will be split into multiple independent, high‑cohesion business units (category management, product publishing, pricing, inventory, etc.) that communicate via lightweight mechanisms, enhancing flexibility.

Each unit adopts workflow orchestration and component selection to quickly support ordinary, composite, or temporary products. The design follows “application split”, “service split”, “data split”, and “application decoupling”, using synchronous RPC and asynchronous MQ to balance scalability and concurrency.

3.2 Evolution: From MVC to DDD

Traditional MVC binds the view to the model, offering fast development but risking code decay when foundations are weak. In practice, services and managers become tightly interwoven, forming a mesh of cross‑calls that erodes maintainability.

After the upgrade, DDD treats each business as a bounded context, separating domain services, events, and repositories. Although the package count increases, the hierarchy becomes clear and maintainable.

We categorize sub‑domains such as main product, category, stock, supplier, inventory, and search, and craft unified domain models that reflect real business shapes, enabling a common language across operations, product, development, and testing.

3.3 Cognitive Rules: Complex Business Silver Bullet

Complexity is inherent to software; DDD reduces it, but we must also build a cognition system. Design principles like SOLID, DRY, and KISS guide us, yet they must be validated and refined through real projects.

4. Business Unitization

We modularize the system into vertical business units (e.g., inventory, procurement, supplier) that expose standardized services. Dependencies are weak; for example, creating a purchase order requires product data from the main product unit, and inventory updates are handled by the inventory unit.

Complex multi‑dimensional queries are decoupled via domain events and asynchronous tasks, syncing data to a generic search unit. Front‑end queries first hit the search layer, then retrieve detailed domain models from the appropriate sub‑domain, achieving single‑responsibility and reducing cross‑calls.

Standardized services abstract variable business rules to the upper layer while keeping core logic stable. For inventory, we expose fundamental actions like “increase”, “decrease”, and “adjust”, supporting diverse scenarios such as sales, procurement, and returns.

This separation allows rapid scaling of development resources per unit, improving overall system stability and aligning with Conway’s law.

5. Empowering the Catering Business

While retail and catering share core product functions, catering adds unique attributes such as seasoning and preparation methods. By extracting common identifiers and extending attribute models, the same business units can support both domains, enabling rapid rollout of new catering features.

Future plans include further modularization (inventory, stock, main product, etc.) with attribute extensions for retail and catering, atomicized logic composition, and unified API interfaces for various front‑ends.

Overall, the architecture upgrade resolves high coupling and low reuse, adopts domain‑driven design for clear business delineation, and enhances system flexibility, stability, and scalability for both retail and catering scenarios.