Building SuNing’s Supply‑Chain Data Platform with DDD and Big‑Data Design

Without grand data governance, we start with a single supply‑chain scenario, taking a small step toward realizing the "data middle platform" concept.

Thinking Part

What Is a Data Middle Platform?

From a literal view, a data middle platform combines data (the core asset generated during production and operation) with the "middle platform" concept popularized by Alibaba in 2015 and widely adopted in 2019. SuNing, an early adopter of cloud architecture, has incorporated the middle‑platform DNA into its data platform development.

Interpretations vary; Alibaba defines a data middle platform as an enterprise‑level data warehouse and lake that collects, computes, stores, and processes massive data, standardizes metrics, provides governance, and offers diverse data services. Because each enterprise’s data capabilities differ, there is no one‑size‑fits‑all solution; a customized platform that fits the company's own context delivers real value.

Our Current Situation and Positioning for Building the Supply‑Chain Data Platform

The platform’s purpose is to provide accurate, timely data services for the supply‑chain domain, supporting both product lines and data analysts.

Figure 1: SuNing Big Data Platform Architecture

Figure 2: SuNing Big Data Product Planning

Although the overall big‑data platform already breaks data silos, a vertical, supply‑chain‑focused middle platform adds value by delivering domain‑specific services, accurate data, and richer analytical context.

Theory Part

Domain Model Definition

The core service domain provides accurate, timely supply‑chain data. A second domain offers a metadata dictionary that maps entity relationships and lineage, serving data governance. The supporting domain handles data ingestion, processing, and storage, completing the three‑domain DDD model.

Figure 3: Data Middle Platform Domain Model

System Architecture Design Model

Guided by the domain model, we adopt a DDD layered architecture: interface, application, domain, and infrastructure layers. This clear separation supports future refactoring, distributed expansion, and micro‑service evolution while keeping the design evolutionary and low‑cost.

1. Interface Layer

Unified entry for external data services, handling REST, API, RPC, and request/response adaptation.

2. Application Layer

Provides service composition and orchestration to quickly meet changing business needs, enhancing reusability and reducing development cost.

3. Domain Layer

Implements core business logic, encapsulating aggregates, entities, value objects, domain services, and events, offering atomic business capabilities for the application layer.

4. Infrastructure Layer

Supplies foundational resources such as MySQL, PostgreSQL, Elasticsearch, HBase, Redis, monitoring, and logging services.

Practice Part

Supply‑Chain Data Platform Architecture Design

Figure 4: Data Platform System Design Model

The architecture consists of four blocks: data collection, storage, governance, and services. Governance catalogs all sub‑domain data, while services provide standardized or customized access. Storage relies on the big‑data platform and search engines; collection uses Kafka and WindQ for high‑throughput, reliable ingestion.

System Implementation Model Design

Figure 5: Data Flow Model

Each layer (interface, application, domain, infrastructure) encapsulates its responsibilities, collaborating to deliver flexible data services. Redundancy and archiving ensure reliability, with degradation mechanisms improving service availability (SAL).

Figure 6: Service Assurance Scheme

Conclusion

Based on DDD domain modeling, the supply‑chain data middle platform design is complete and development is progressing rapidly. Although some details need refinement, SuNing has taken a solid first step toward a data‑driven future.