关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。负责：
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考：
1 前言
受限于对业务掌握度及对应数据特性的了解，大数据平台更倾向海量的同构或异构数据采集，清洗，加工，存储。而提供的数据服务更多是对采集到数据进行汇总及分析。
供应链域数据中台专注供应链域业务数据，优势是具备熟练掌握相关业务的产品和开发，更了解业务和数据特性：
- 为产品线提供准确及时的数据服务
- 也为数分提供完善的数据脉络，帮助其更好对这些数据深层挖掘分析，再次提升数据价值
系统设计上也将考虑系统能做到能进能退：
- 进则作为独立数据域的数据中台产品，逐渐完善自身特性
- 退则作为一个数据域模块快速融入公司大数据中台
2 理论篇
有了存在意义和价值空间，接下来考虑如何构建。采用DDD构建数据中台的各类模型。结合当下情况分析，自顶向下的策略更适合。首先目标建立供应链域数据中台，顶层领域已限定供应链。其次该策略不受限于当前系统，适合用 DDD 领域逐级分解的建模方法。
2.1 领域模型界定
现阶段业务需求是给相关业务系统提供准确及时的供应链域数据服务，同时也是数据中台核心服务，所以作为主体的数据服务是毫无争议的核心域。
数据中台第二个重要功能是提供元数据字典服务，即提供有关联关系的元数据的脉络服务。
其展示该域下各数据实体的关联关系及链路节点出处，以及相关数据服务详情介绍等，可称之为数据治理，作用上区分可将数据治理归为通用域。数据治理和数据服务的共同基石则是数据，这里指出的就是数据中台另一个功能同时也是本质功能，打通数据孤岛对数据的采集加工和存储，这些就组成另外一个子域，归为支撑域。
数据中台域模型图：
系统架构设计模、领域模型界定完毕后，下面就是以领域模型为指导进行系统架构模型的设计。系统架构模型设计依然用 DDD。
搭建有自身特色的数据中台，决定我们没有可参考案例，为防过度设计，提前设定一个设计方针，即系统架构须是一个演进式，经得起破坏和重构，才能满足低成本，快建设，快试错。大而全系统架构设计虽也是我们向往，但现状不许。
2.2 数据中台系统设计模型
① 接口层
数据中台对外服务的统一入口：
- 对接各种类型的访问请求，如restful 接口，api接口，RPC框架服务接口等
- 提供服务适配，对各种类型接口提供请求参数和返回结果集的适配相关的服务
② 应用层
实现服务组合和编排，以快速满足业务需求。不可否认用户需求一直在变化。能做的就是如何快速响应这些变化，服务组合和重新编排，提升服务可重用性，降低重复功能的开发成本，提升开发效率，为业务的快速试错提供了很好支撑。
③ 领域层
该层实现核心业务逻辑，同时聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。通俗易懂的，是实现了业务处理逻辑的服务原子化，按业务逻辑将服务细分，细分后的原子服务将脱离具体的业务模式，为应用层的服务组合和编排提供“原材料”。
④ 基础层
贯穿所有层，为各层提供基础资源服务。包含MySQL，PG，ES，HBase和Redis等数据存储和缓存服务。
还有一部分重要组成就是公共服务，好产品离不开监控运维和相关日志服务，这些是保障系统健康的重要措施。
3 实践篇
3.1 供应链域数据中台系统架构设计
数据中台系统架构设计模型：
- 数据治理将供应链全链路涉及到或者相关的所有子域的数据进行目录化管理
- 数据服务则基于所有子域数据提供标准或者定制化的服务
- 数据存储则主要依赖大数据平台和搜索，是基于数据中台的数据的量级和服务的便利性以及可用性考虑
- 数据采集基本是 kafka 和 数据同步组件，基于数据的吞吐量和可靠性考虑
3.2 系统实现模型设计
数据中台数据流转模型（数据中台服务保障方案）：
如图所示，按既定接口层/应用层/领域层/基础层设计，逐层封装，各层相互协作，对业务系统提供灵活的数据服务，很好地实现了各层分工，便于快速响应业务需求。
考虑到数据中台主要为业务系统提供数据服务，为保障数据服务的可靠性和及时性，还得兼顾系统性能和稳定，对数据服务做了冗余和归档服务。冗余的服务同时具备降级职责，提升服务 SAL 指标。
4 总结
基于 DDD 领域建模的供应链域数据中台设计基本完毕，紧接着就是后续流畅的开发工作。复盘过程，虽不甚完美，“先开枪后瞄准”至少在探索数据中台领域迈出第一步，那么成功就不会太远。