Inside the Unified Order Shipping Center: Scalable Logistics Architecture

1. What is the Order Shipping Center?

The Order Shipping Center is defined as Model + Process (state machine) + Data & Algorithms . It serves as a company‑level core capability, turning the platform product from connecting to "vehicles" into connecting to "orders".

It establishes connection standards for various business systems (including external shipper systems, TMS, OMS) and provides unique value streams based on order data.

2. Introduction

In the fast‑changing digital economy, platformization drives operational efficiency and user experience. This article deep‑dives into the technical architecture of the Order Shipping Center, covering scalability, flexibility, and logistics‑specific business insights. The center comprises order model services, shipping model services, and domain event services, supporting dynamic cargo specifications, revenue/expense models, and state machines for transportation processes.

3. Architecture Goals

The center becomes the foundational service for all products and applications handling orders.

It defines connection standards for external and internal systems and delivers rapid integration (at least 3× R&D efficiency).

4. Architecture Principles

The center does not contain business processes or own business data.

Technical boundaries with commercial products are defined as:

External integration and node feedback.

Platform handles data integration and flow; business systems read/write based on platform standards.

The center does not directly modify business process data; fields are authenticated and business parties ensure accuracy and timeliness.

Platform manages document data types and attributes.

Data fields are categorized as:

Service fields : required for platform services (model + state machine + algorithms).

Shared fields : common across multiple business systems.

Connection fields : for external‑internal system linkage.

5. Business Value

Provides a foundational order model for all products.

Enables rapid integration with downstream systems, boosting development efficiency.

Offers flexible, extensible APIs and domain events for fast product delivery.

Supports compatibility with multiple existing order modules and establishes governance standards.

6. Overall Architecture

Three‑layer value diagram (image omitted for brevity).

7. Deployment Structure

Current deployment diagram (image omitted).

8. Technical Challenges

Key challenges include ambiguous implementation boundaries, high R&D cost, platform product design, and architecture design. Specific issues:

Unclear technical boundaries can create pitfalls.

Ensuring extensibility and flexibility of the order model.

Maintaining global data sequencing across systems.

Synchronizing data between internal and external systems.

Guaranteeing eventual data consistency.

9. Product Capabilities

After six months of iteration, the center supports comprehensive order and shipping document structures, enabling full‑process tracking for shippers and carriers.

9.1 Order Capabilities

Record and query various order commitments (single/multiple loading/unloading).

Support sub‑order splitting by cargo volume or node.

Enable carrier‑to‑carrier (transit) assignment.

Customizable dynamic state machine and event model.

Operation logs for creation, modification, deletion, and transport processes.

9.2 Shipping Capabilities

Record and query shipping information for various loading/unloading scenarios.

Decouple shipping documents from transport resources, allowing vehicle/driver changes.

Customizable dynamic state machine and event model.

Operation logs for creation, modification, deletion, and transport processes.

9.3 Cargo Tracking Example

Illustrative diagram of cargo flow (image omitted).

10. Core Architecture Design

10.1 Data Model

The platform manages metadata for order and shipping models, supporting dynamic extension fields.

Platform standard fields : tenant code, order ID, shipping ID, relationships.

Business standard fields : short‑tool service fields registered on the platform.

Business custom fields : scenario‑specific fields registered on the platform.

Additional principles include user center integration, model iteration, data authentication, internationalization (multi‑language, timezone, currency, encoding, geolocation), and back‑trace capabilities for orders and cargo.

10.1.2 Extensible Capabilities

{
  "extension": [
    {
      "biz_system": "cyt",
      "properties": {
        "group_id": "",
        "company_id": ""
      }
    }
  ]
}

{
  "goods_specs": {
    "quantity": "",
    "weight": "",
    "volume": "",
    "number": ""
  }
}

{
  "income_outgo_freight": [
    {
      "type": "outgo_freight",
      "item": "total_freight_payable",
      "amount": "",
      "currency_type": ""
    }
  ]
}

10.2 Metadata Engine

The engine drives hot‑updates of fields and tables without traditional development cycles, supporting standard APIs and asynchronous domain events.

10.3 Collaboration Engine

Implements 28 collaboration rules to manage complex business logic and data security across multiple systems.

10.3.1 Collaboration Example

Shows how a hazardous‑industry carrier reports electronic shipping documents to a regulatory platform (diagram omitted).

10.3.2 Collaboration Service

Provides three core interfaces: rule execution, result status update, and exception check (diagram omitted).

10.4 State Machine & Event Model

Adopts Finite State Machine (FSM) concepts with states, events, and actions. The platform defines state fields, enums, and event definitions, while commercial products handle state transitions, validations, and business logic.

State(S) x Event(E) -> Actions(A), State(S')

10.4.2 State Machine Capabilities

Platform provides state field definitions and enums.

Platform defines domain event data fields.

Business products decide which state machines change after an event.

Business products perform validation and control.

Platform records back‑trace data for state machines and events.

10.5 API Orchestration

Establishes unified API specifications and patterns to connect heterogeneous systems, reducing implementation cost by at least 70%.

10.5.1 Goals

Define technical specs for API orchestration services.

Create implementation patterns for multi‑system connections.

Achieve higher efficiency and lower cost than traditional development.

10.5.2 Scope

Synchronous external system updates to internal order data.

External system calls for order/shipping APIs (e.g., freight quoting).

Mid‑layer protocol adaptation when neither system can be modified.

10.6 Microservice Design

Follows single‑responsibility, autonomy, domain‑driven, interface‑or‑message, and decentralization principles. The center is split into order and shipping microservices.

10.7 Project Delivery

Highlights key deliverables such as delegation models, state machines, API orchestration, collaboration engine, custom tags, third‑party callbacks, and SDKs that dramatically improve integration efficiency.

12. Future Architecture Evolution

12.1 Model Application

Deepens order and shipping model usage across business flows and supports industry‑specific transport processes via a workflow engine.

12.2 Connection Hub

Builds a configurable connection hub, including API orchestration components.

12.3 Metadata Engine Advancement

Extends code generation to cover all field and table additions and enhances dynamic data interaction.

12.4 Permission Model

Implements a Linux‑like permission model (read, write, execute) for data fields, with binary representation (e.g., 775) to control access for business owners, platform, and other parties.

12.5 Data Retrieval Service

Provides a data retrieval capability similar to a spreadsheet engine while avoiding multi‑storage synchronization complexities.

Overall, the Order Shipping Center’s architecture evolves continuously to provide a scalable, flexible, and extensible logistics platform that bridges multiple business systems and delivers tangible value.