How We Unified Retail and Catering Product Platforms with DDD‑Driven Architecture

Introduction

As consumer demands diversify and market competition intensifies, the retail and catering sectors face unprecedented opportunities and challenges. Companies need flexible, efficient systems. After upgrading the retail product system architecture, we tackled the next challenge: elegantly integrating the catering product system into a shared unified product platform.

Phase 1: Retail Product Architecture Breakthrough

The retail system upgrade was a deep transformation that addressed technical debt and laid a solid foundation for future expansion. Key breakthroughs after multiple iterations include:

Business Decoupling : Using Domain‑Driven Design (DDD) to split the massive product system into independent business units such as 主商品, 类目, 库存, 供应商, 进销存, 搜索, 商家工具, each with clear boundaries and responsibilities.

Domain Model Construction : Abstract stable domain models for each unit, separating business logic from complex technical details.

Service Standardization : Move core business logic to the domain layer and provide standardized domain and repository services for flexible composition.

Data Structure Optimization : Redesign underlying data models, e.g., using JSON fields for multi‑dimensional pricing and Elasticsearch for complex queries.

After the upgrade, adding new features such as 一品多码, 多包装, 条码秤, 自营外卖, 门店商品克隆 became straightforward and highly efficient.

Phase 2: Catering Product Challenges

Following the retail upgrade, we turned to the catering business, which handles around 30 million items and processes over 3 million orders daily. Rapid growth, frequent feature iteration, and complex play‑books have caused “entropy increase,” raising system complexity, management difficulty, and maintenance cost.

Key pain points :

1. Architectural constraints : Traditional MVC leads to high coupling between sub‑domains.

2. Blurred service boundaries : A single RPC service mixes SPU, SKU, waterline, additives, flavor methods, tags, etc., with many *manager and *mapper methods.

3. Lack of domain model : Business logic is scattered across layers, tied to database table structures.

4. Insufficient extensibility : A large product cache includes many attributes; any change invalidates the whole cache.

Why Merge?

Although retail and catering serve different scenarios, both revolve around products and share many common attributes (name, image, category, channel, unit, sales mode, multi‑dimensional pricing, etc.) and similar CRUD operations. Differences lie in catering‑specific features such as flavor methods, additives, sales periods, and combos, while retail focuses on standardized packaging, inventory, suppliers, barcodes, and weight‑based pricing.

We aim to eliminate duplicate development of common business while preserving specialized capabilities, and to replace the legacy, isolated catering architecture with a shared foundation.

Practical Path of Architecture Upgrade

We adopted an incremental, spiral approach, dividing the large task into manageable sub‑tasks across vertical and horizontal dimensions.

Vertical Dimension

The API gateway becomes the unified entry point, routing requests to appropriate executors. A fusion gateway standardizes business code, scenario, operator, store ID, and parameters, allowing seamless integration of retail and catering services.

Core services such as product management (AI‑assisted creation, batch unit updates, status changes) and inventory management have already been unified.

Horizontal Dimension

We focused on the “add‑on” domain as the first slice, addressing architectural, data‑model, performance, and maintainability issues. Measures included defining DDD models, decoupling sub‑domains via events, optimizing tables, extracting add‑on cache, refactoring saveBatch interfaces, and implementing gray‑release and rollback mechanisms. Result: P99 latency reduced from ~20 ms to 9 ms, database access cut by 50%.

Subsequent units (flavor methods, combos, search, etc.) will follow the same DDD‑driven, low‑coupling approach.

Conclusion

Integrating retail and catering products is not a simple system merge but a domain‑driven redesign that builds a flexible, extensible unified product platform, gradually eliminating technical debt while preserving business uniqueness.