Designing a Reusable Shared Order Service: Boundary Definition and Internal Architecture

Order Business Architecture

The article introduces an O2O (Online‑to‑Offline) order scenario where orders originate from a mini‑program/App or from third‑party delivery platforms and are synchronized to store POS systems for processing.

Order Service Boundary Definition

The service should focus on three core functions: basic order information management, order discount management, and order lifecycle management. Clear boundaries prevent disputes and keep the service focused.

Responsibilities that are explicitly excluded from the order service include:

Calling other services directly; aggregation services should be used when cross‑service data is needed.

Integrating third‑party systems; dedicated sync programs handle external platform interactions.

Performing discount calculations or cost‑allocation logic; the service only stores discount results while dedicated promotion or finance services compute them.

Providing detailed fulfillment or logistics information; such data belongs to downstream fulfillment systems.

Internal Design of the Order Service

The article discusses abstracting the data model to support generic order status handling. It proposes a two‑level status design: a "main status" managed by the service with well‑defined transition rules, and a "sub‑status" left to applications for fine‑grained scenarios.

Two approaches for status management are presented:

Fully open status definition, where callers supply any status value—flexible but risky.

Combined main/sub status, where the service enforces core state transitions while applications manage detailed sub‑states, balancing safety and flexibility.

Order Service Interface Definition

External interaction can be synchronous (API calls) or asynchronous (message notifications). Synchronous APIs are offered in three granularities:

Coarse‑grained: returns only essential fields (e.g., order ID, status, amount).

Medium‑grained: returns a common set of frequently used fields.

Fine‑grained: returns the full order detail.

Asynchronous notifications are categorized as "fat" (full payload) or "skinny" (minimal payload) messages, allowing consumers to choose between completeness and transmission efficiency.

Tip: Sync programs can subscribe to order service messages to receive real‑time updates without tight coupling.

Conclusion

To create a highly reusable shared service, developers must clearly define service boundaries and apply abstract internal designs—especially for status management and interface granularity—so the service remains flexible across diverse business scenarios.