Design and Architecture of an E‑commerce Order System

The article discusses the role of an order system in traditional e‑commerce enterprises, summarizing its main functional modules and design ideas, and offering thoughts on future development.

Before building an order system, it is essential to map the relationships between overall business systems and the order system’s upstream and downstream boundaries to define its responsibilities and functions.

Order system relationships with various business systems are illustrated:

External Systems : Front‑end platforms for customers, merchant back‑ends, and channel integrations (e.g., banks, WeChat) that directly face users.

Management Middle‑Office : Modules such as order service, promotion service, product service, and content service that manage core business functions.

Common Service Systems : Shared services (e.g., product, user, payment) that provide foundational capabilities to other applications.

The order system’s upstream/downstream relationship shows it receiving user information, converting it into product orders, and interacting with product, promotion, warehouse, membership, and payment systems.

Business Architecture includes:

Order Service – user‑facing functions such as order list, detail, and placement, plus data services for other modules.

Order Logic – core lifecycle management (creation, payment, production, confirmation, completion) with complex status and amount rules.

Underlying Services – modular public services (product, user, inventory) accessed via unified interfaces to avoid scattered calls.

Core Order Functions :

Order creation involves gathering product, discount, membership, and payment information. Inventory reduction can be handled either at order time (immediate deduction) or payment time (deduction after payment), each with advantages, disadvantages, and mitigation strategies such as order expiration, purchase limits, and risk control.

Order Splitting occurs when items come from different channels or when SKU‑level constraints (different warehouses, shipping requirements) require separate sub‑orders.

Reverse Flow covers order modification, cancellation, refund, and return, each with specific interactions with inventory, promotion, and payment systems.

State Machine defines three elements – current state, action, and next state – to manage order status transitions, often with multiple state machines for different order types.

Future development notes that growing business volume may lead to multiple parallel order systems, causing fragmented data and duplicated maintenance. A unified order center combined with specialized business order systems is proposed to centralize data and provide consistent services.

In conclusion, building an enterprise order system should balance breadth and depth, aligning design with market, company, and business realities to create a coherent, maintainable architecture.