Why Upgrade Retail Systems from MVC to DDD? A Deep Dive into Architecture

1. Introduction

In today’s fast‑changing retail industry, the main product module has become increasingly complex, much like entropy in a system: a simple start evolves into a highly intricate architecture as business requirements iterate.

If the early architecture is poorly designed, chaos grows over time, making development and maintenance difficult. This article explores how to upgrade a retail main‑product system from an MVC architecture to a Domain‑Driven Design ( DDD) architecture to address these challenges and improve system flexibility.

2. System Diagnosis

Before upgrading, a comprehensive diagnosis of the current system is essential. Architecture should start from high‑level business needs, decompose them top‑down, and abstract them bottom‑up, using appropriate design patterns and principles.

2.1 MVC Lacks Domain Depth

The current system uses an MVC architecture with anemic models and procedural code. Data flow follows "read → compute/assemble → store" and tightly couples UI with underlying data structures.

Adding new 存储字段 (storage fields) seems to meet requirements but weakens domain modeling, over‑relies on 表结构 (table structures), and loses business semantics. Communication with product teams also becomes overly technical, leading to misunderstandings.

2.2 Over‑Coupled Modules

Developers often bypass standard interfaces and directly invoke internal components, causing tangled controller, service, and manager layers. This "broken‑window" effect makes even small changes painful.

2.3 Bloated Table Structures

Complex tables increase data‑operation difficulty and degrade database performance. Optimizing tables, removing redundant fields, and designing better data models are crucial.

2.4 Weak Extensibility

Operations like deleting a product and moving it to a log table work for simple cases, but when an order contains multiple product details, physical deletion from biz_spu and migration to product_delete_log can cause missing data on order detail pages.

3. DDD Main Architecture

Domain‑Driven Design focuses on core business, achieving high collaboration between business and technology.

Sub‑domains are divided into 核心域 (core domain), 通用域 (generic domain), and 支撑域 (support domain). By extracting a 领域模型 (domain model) and driving business actions around it, business and technical complexity are separated, improving extensibility.

3.1 Business Analysis

Understanding requirements from merchant, buyer, and platform perspectives reveals numerous functions such as template configuration, product creation, pricing, packaging, and more.

3.2 Domain Modeling

Modeling maps real‑world concepts to software attributes. Common techniques include use‑case analysis, four‑color modeling, and event‑storming to identify nouns and verbs, forming entities like SPU and SKU.

These entities reside in the domain layer ( model) and expose services ( service) for CRUD operations, keeping business logic encapsulated.

Bounded contexts (e.g., inventory, supplier) are isolated via packages, while infrastructure (repositories, caching) resides in the infrastructure layer.

4. Exploring Optimization Details

DDD provides a structural skeleton, but concrete implementation details are vital for robustness.

4.1 Domain‑Data Model Mismatch

Product pricing involves many fields (sale price, cost, member price, etc.). Storing each as separate rows caused table bloat. By recognizing a "read‑many, write‑few" pattern, the design switched to a generalized JSON column, simplifying reads and supporting future price types.

4.2 Data Structure Refactoring

Optimizations include data aggregation (merging frequently joined tables), intentional redundancy (duplicating barcode data for quick validation), structural cleanup (removing low‑value tables), and vertical splitting (moving low‑frequency fields to an extension table).

4.3 Non‑Core Domain Extraction

Applying a "divide‑and‑conquer" mindset, auxiliary domains like "waterline" and "multi‑packaging" are separated from the core product domain, reducing coupling while preserving necessary references.

4.4 Data Heterogeneity for Rich Queries

Primary data remains in RDS, but to meet complex search needs, an Elasticsearch layer is introduced via a data‑heterogeneity architecture, syncing data through MQ and providing specialized indexes for scenarios such as recommendations and price analysis.

Conclusion

The article delved into the necessity of migrating a retail main‑product system from MVC to DDD, identified pain points such as shallow domain modeling, tight coupling, bloated tables, and limited extensibility, and presented DDD‑driven solutions with detailed optimizations ranging from model‑data mapping to data‑structure refactoring and heterogenous query support, ultimately delivering a more maintainable and competitive system.