1 前言
受限于对业务掌握度及对应数据特性的了解，大数据平台更倾向海量的同构或异构数据采集，清洗，加工，存储。而提供的数据服务更多是对采集到数据进行汇总及分析。
供应链域数据中台专注供应链域业务数据，优势是具备熟练掌握相关业务的产品和开发，更了解业务和数据特性：
- 为产品线提供准确及时的数据服务
- 也为数分提供完善的数据脉络，帮助其更好对这些数据深层挖掘分析，再次提升数据价值
系统设计上也将考虑系统能做到能进能退：
- 进则作为独立数据域的数据中台产品，逐渐完善自身特性
- 退则作为一个数据域模块快速融入公司大数据中台
2 理论篇
有了存在意义和价值空间，接下来考虑如何构建。采用DDD构建数据中台的各类模型。结合当下情况分析，自顶向下的策略更适合。首先目标建立供应链域数据中台，顶层领域已限定供应链。其次该策略不受限于当前系统，适合用 DDD 领域逐级分解的建模方法。
2.1 领域模型界定
现阶段业务需求是给相关业务系统提供准确及时的供应链域数据服务，同时也是数据中台核心服务，所以作为主体的数据服务是毫无争议的核心域。
数据中台第二个重要功能是提供元数据字典服务，即提供有关联关系的元数据的脉络服务。
其展示该域下各数据实体的关联关系及链路节点出处，以及相关数据服务详情介绍等，可称之为数据治理，作用上区分可将数据治理归为通用域。数据治理和数据服务的共同基石则是数据，这里指出的就是数据中台另一个功能同时也是本质功能，打通数据孤岛对数据的采集加工和存储，这些就组成另外一个子域，归为支撑域。
数据中台域模型图：
系统架构设计模、领域模型界定完毕后，下面就是以领域模型为指导进行系统架构模型的设计。系统架构模型设计依然用 DDD。
搭建有自身特色的数据中台，决定我们没有可参考案例，为防过度设计，提前设定一个设计方针，即系统架构须是一个演进式，经得起破坏和重构，才能满足低成本，快建设，快试错。大而全系统架构设计虽也是我们向往，但现状不许。
2.2 数据中台系统设计模型
① 接口层
数据中台对外服务的统一入口：
- 对接各种类型的访问请求，如restful 接口，api接口，RPC框架服务接口等
- 提供服务适配，对各种类型接口提供请求参数和返回结果集的适配相关的服务
② 应用层
实现服务组合和编排，以快速满足业务需求。不可否认用户需求一直在变化。能做的就是如何快速响应这些变化，服务组合和重新编排，提升服务可重用性，降低重复功能的开发成本，提升开发效率，为业务的快速试错提供了很好支撑。
③ 领域层
该层实现核心业务逻辑，同时聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。通俗易懂的，是实现了业务处理逻辑的服务原子化，按业务逻辑将服务细分，细分后的原子服务将脱离具体的业务模式，为应用层的服务组合和编排提供“原材料”。
④ 基础层
贯穿所有层，为各层提供基础资源服务。包含MySQL，PG，ES，HBase和Redis等数据存储和缓存服务。
还有一部分重要组成就是公共服务，好产品离不开监控运维和相关日志服务，这些是保障系统健康的重要措施。
