AIGC革命已来,如何在企业场景落地?如何选择模型、怎样应用RAG、需要哪些组织流程配套? 了解详情
写点什么

DDD 领域模型设计数据中台落地——苏宁供应链域数据中台构建实践

  • 2020-08-12
  • 本文字数:3256 字

    阅读完需:约 11 分钟

DDD领域模型设计数据中台落地——苏宁供应链域数据中台构建实践

没有豪横的数据规划治理和服务,有的只是我们从供应链域一个业务场景的切入,迈出落实“数据中台”概念的一小步。古人有云“积土成山,风雨兴焉,积水成渊,蛟龙兴焉”,我们相信从小的业务场景的积累和沉淀,不断演进迭代,最终能构建成自身特色的数据中台。下面是通过三个篇幅复盘我们的供应链域数据中台的实践过程,做一个阶段性的总结。

1 思考篇

数据中台是什么?

从字面解释数据中台就是数据 + 中台,数据是什么大家都能很好理解,就是企业在生产或经营过程中产生的信息,是企业的核心资产之一。那么中台呢?业间流传最多的是源自 2015 年阿里提出的“大中台,小前台”的战略。中台概念真正火起来则是 2019 年,相对于 2013 年称之为“大数据元年”,2017 年称之为“AI 元年”,2019 年则是当之无愧的“中台元年”。整个 19 年毫不夸张的说“中台”概念火遍互联网行业,苏宁作为国内第一批架设云架构的企业, 2015 年以前和 IBM 的联合项目组已经提出过“中台”概念,并逐步落实到相关业务管理中。身处基因概念盛行的互联网行业,我们建设数据中台天生有了“中台”的 DNA。


概念到落实还需要理解,“一千个人心中就有一千个哈姆雷特”每个人对中台的概念解读或多或少都有不同之处。阿里对数据中台概念的解读则是“大数据时代下,通过数据技术对海量数据进行采集、计算、存储、加工,同时统一标准和口径,具有数据治理和资产分析能力的,提供数据服务方式多样的企业级数据仓库与数据湖”。中台既然归集于企业级业务和数据的沉淀,每个企业的数据能力和业务现状又是千差万别的,理论上说不存在一套放之各个企业皆行之有效的数据中台解决方案!盲目的跟风蹭热点,为了中台而中台,最终结果竹篮打水一场空。所以从各自企业自身的现状出发,搭建有自己特色的数据中台,才是真正意义上的数据中台,才能发挥数据中台的最大价值。

搭建供应链域数据中台,我们的现状和定位是什么样的?

这个问题也是我们供应链域数据中台存在的意义和价值。经过几年的不懈努力和迭代优化,苏宁现在已经有了完善的大数据平台技术架构和大数据分析产品线规划,为苏宁的整体经营和决策提供强有力的数据支撑。



图 1:苏宁大数据平台技术架构



图 2:苏宁大数据产品规划


乍一看,我们规划的供应链域数据中台似乎没有存在的意义和价值空间,大数据平台已经打通了各个业务域的数据孤岛,丰富的数据产品线也提供了较为全面的数据服务。但仔细分析一下,不难发现垂直细分领域还是存在价值空间的。


受限于对业务的掌握程度以及对应的数据特性的了解,大数据平台更倾向于海量的同构或者异构数据的采集,清洗,加工,存储。而提供的数据服务更多的是对采集到数据进行汇总以及分析。供应链域数据中台将专注于供应链域业务数据,我们的优势是具备熟练掌握相关业务的产品和开发,我们更了解业务和数据特性。一方面可以为产品线提供准确及时的数据服务。另一方面为数据分析人员提供完善的数据脉络,帮助其更好的对这些数据进行更深层次挖掘分析,进一步提升数据的价值。另外系统设计上我们也将考虑系统能做到能进能退,进则作为独立数据域的数据中台产品,逐渐完善自身特性。退则作为一个数据域模块快速融入苏宁大数据中台。

2 理论篇

有了存在的意义和价值空间,接下来是考虑如何构建。这里我们主要采用了当下流行的 DDD(DDD,Domain-Driven Design) 领域建模的方法构建数据中台的各类模型。结合我们目前的的情况分析,自顶向下的策略更适合我们。首先我们的目标是建立供应链域的数据中台,顶层领域已经限定于供应链。其次该策略不受限于当前系统,适合用 DDD 领域逐级分解的领域建模方法。

领域模型界定

现阶段我们的业务需求是给相关业务系统提供准确及时的供应链域的数据服务,同时这也将是数据中台的核心服务,所以作为主体的数据服务是毫无争议的核心域。数据中台的第二个重要功能是提供元数据字典服务,更准确的说法是提供有关联关系的元数据的脉络服务。其展示该域下各个数据实体的关联关系以及链路节点出处,以及相关数据服务详情介绍等等,这些可以称之为数据治理,从作用上区分可以将数据治理归集为通用域。数据治理和数据服务的共同基石则是数据了,这里指出的就是数据中台另外一个功能同时也是本质功能,打通数据孤岛对数据的采集加工和存储,这些就组成了另外一个子域,我们归集为支撑域。DDD 领域模型的三大域界定完毕。



图 3:数据中台域模型图


系统架构设计模型 领域模型界定完毕后,下面就是以领域模型为指导进行系统架构模型的设计了。系统架构模型的设计我们依然采用 DDD,DDD 分层架构模型包括接口层、应用层、领域层和基础层。通过分层架构设计,一方面使各层的职责边界的界定非常清晰,为将来系统的重构,分布式扩展或微服务化打下很好的基础,另一方面又能确保各层能有条不紊地分工协作。


搭建有自身特色的数据中台,决定了我们没有可参考的案例,为了防止过度设计,我们提前设定了一个设计方针,那就是我们的系统架构必须是一个演进式的,经得起不断的破坏和重构,这样才能满足我们低成本,快速建设,快速试错的目标。大而全的系统架构设计虽然也是我们向往的,但现状不允许。



图 4:数据中台系统设计模型图


1. 接口层


数据中台对外服务的统一入口。一方面对接各种类型的访问请求,例如:restful 接口,api 接口,RPC 框架服务接口等等。另一方面提供服务适配,对各种类型接口提供请求参数和返回结果集的适配相关的服务。


2. 应用层


实现服务组合和编排,用于快速满足业务需求。不可否认我们的用户和用户的需求唯一不变的就是变化。我们能做的就是如何快速响应这些变化,服务的组合和重新编排,提升了服务的可重用性,降低了重复功能的开发成本,提升了开发效率,为业务的快速试错提供了很好的支撑。


3. 领域层


按 DDD 的领域模型理解,该层实现了核心业务逻辑,同时聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象,以及它们组合所形成的业务能力。用个通俗易懂的说法,是实现了业务处理逻辑的服务原子化,按业务逻辑将服务细分,细分后的原子服务将脱离具体的业务模式,为应用层的服务组合和编排提供“原材料”。


4. 基础层


贯穿所有层,为各层提供基础资源服务。包含了我们常用的 mysql,postgre,es,hbase,redis 等等数据存储和缓存服务。还有一部分重要组成就是公共服务,一个好的产品离不开监控运维和相关日志服务,这些是保障系统健康的重要措施。

3 实践篇

供应链域数据中台系统架构设计


图 5:数据中台系统架构设计模型


如上图所示,我们系统的架构设计分为四块 - 数据采集,数据存储,数据治理,数据服务。其中数据治理将供应链全链路涉及到或者相关的所有子域的数据进行目录化管理。数据服务则基于所有子域数据提供标准或者定制化的服务。数据存储则主要依赖大数据平台和搜索,是基于数据中台的数据的量级和服务的便利性以及可用性考虑。数据采集更多是 kafka 和 windq,基于数据的吞吐量和可靠性考虑。

系统实现模型设计


图 6:数据中台数据流转模型


如上图所示按照既定的接口层,应用层,领域层,基础层涉及。逐层封装,各层相互协作,对业务系统提供灵活的数据服务,很好实现了各层的分工,快速响应业务需求。考虑到数据中台主要为业务系统提供数据服务,为保障数据服务的可靠性和及时性,同时兼顾系统的性能和稳定,对数据服务做了冗余和归档服务。冗余的服务同时具备降级的职责,提升服务的 SAL 指标。如下图所示



图 7:数据中台服务保障方案

4 结束语

我们基于 DDD 领域建模的供应链域数据中台的设计基本完毕,后续的开发工作也在紧锣密鼓的实施。反观整个过程虽然不是很完美,存在一些考虑不够细致地方,对 DDD 领域建模的一些概念也可能存在偏差。“先开枪后瞄准”至少我们在探索数据中台的领域迈出了坚实的第一步,未来是康庄大道还是遍地荆棘已经不重要了,迈出了这第一步,其实成功就离我们不远了。

作者介绍

胥磊,苏宁科技集团供应链平台研发中心采购中台技术负责人,对供应链采购业务域有丰富系统建设经验,先后负责过采购平台的搭建,采购平台向采购中台的演进。目前主要负责采购中台的规划落地实施。


2020-08-12 14:404863

评论 11 条评论

发布
用户头像
DDD应该更偏向于业务领域的建模,个人感觉更适合用于数仓当中主题划分,类似于电商数仓中有用户主题或者叫用户域、商品域、订单域等。电商数仓建设中的可以仓考业务领域划分的部分。 个人见解,仅供参考
2020-08-17 17:53
回复
用户头像
数据中台应该不太匹配ddd的,ddd是领域建模的,关注的是业务规则、流程,已经到了数据这个层面,核心就是查询和分析了,对应ddd应该属于查询模型的范畴
2020-08-13 08:40
回复
是的,查询和分析的确是数据中台的核心服务,但是并不是唯一的。数据治理和数据的采集存储存储也是很重要的,缺失其中任何一块都是不行的,做好数据中台这三块是密不可分的
2020-08-13 14:56
回复
用户头像
真的审核过吗?编辑
2020-08-12 22:16
回复
这只是我们业务域数据中台搭建前后的复盘总结,有问题欢迎沟通交流
2020-08-13 15:31
回复
用户头像
没有深入描述DDD如何实践的,差评
2020-08-12 18:00
回复
介于篇幅和文章主旨,更多是借鉴了ddd的战略和战术思想,没有过多的写实践。要深入了解ddd推荐下极客时间欧创新老师的DDD实战课
2020-08-13 14:59
回复
用户头像
这不就是最主流的大数据平台架构,老酒装了个“中台”+“领域模型”的新瓶。
2020-08-12 16:59
回复
可能前面罗列的我们公司大数据平台技术架构和产品规划篇幅有点重,真实想法是再这种主流的日趋完善的大数据平台架构下,博得具体业务域的数据中台的一块空间。至于领域模型更多的是借鉴了其中的思想,系统设计的战略思想和系统实现的战术思想
2020-08-13 15:10
回复
用户头像
图3这个不是传统概念中的的模块吗? 和领域驱动的“域”有关系吗?DDD领域驱动设计应该是service以下层面的设计上的概念。DDD是种面向对象的设计哲学,和业务划分关系不大吧?DDD的推动只能普及概念,然后自下而上地推进。否则业务架构做得再好,子系统还是在用传统的那些设计。
2020-08-12 16:12
回复
冒昧贴下欧老师的一句话回复一下“DDD 是一种设计思想,它可以同时指导中台业务建模和微服务设计,它们之间就是这样的一个铁三角关系”,个人理解的设计思想用于业务层面是战略设计,系统实现层面是战术了,两者配合才相得益彰。子系统还沿用老一套的话又会逐渐做成一个大单体应用,远离初衷了
2020-08-13 15:21
回复
没有更多了
发现更多内容

数据艺术,成就科学现代的全面预算管理模式

智达方通

数据分析 数据驱动 智达方通 数据叙事

传统大数据迁移遇到的问题与解决方案

镭速

大数据迁移

跟单交易所开发,合约跟单交易系统开发

V\TG【ch3nguang】

寻找协调器FindCoordinatorRequest请求流程

石臻臻的杂货铺

Kafk

云原生Spark UI Service在腾讯云云原生数据湖产品DLC的实践

腾讯云大数据

数据湖

HarmonyOS应用开发—资源分类与访问

HarmonyOS开发者

HarmonyOS

教你2种方法,将iOS设备通过MQTT协议连接到华为云物联网平台

华为云开发者联盟

云计算 后端 华为云 华为云开发者联盟 企业号9月PK榜

矩视快问快答

矩视智能

机器视觉 深度学习、

两行代码实现Redis消息队列,简单易用

高端章鱼哥

redis 消息列队

mac电脑推荐 LRTimelapse for Mac延时摄影视频

mac大玩家j

Mac软件 摄影软件 摄影后期处理软件

GaussDB技术解读系列丨运维自动驾驶探索

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号9月PK榜

【玩转鲲鹏 DevKit系列】如何快速迁移无源码应用?

华为云开发者联盟

后端 开发 华为云 华为云开发者联盟 企业号9月PK榜

12个强大的 JavaScript 动画库,可帮助你提升用户体验

互联网工科生

JavaScript 动画库

面试官:说一下 MyBatis 缓存机制?

王磊

Java Java面试题

NFTScan 正式上线 TON NFTScan 浏览器!

NFT Research

NFT\

ShutdownHook妙用

FunTester

数据库重构之路,以 OrientDB 到 NebulaGraph 为例

NebulaGraph

数据库

企业文件传输遇到的问题与解决方案

镭速

大文件传输 数据文件传输

腾讯云生态以退为进,让「半条命」撑起「半边天」

ToB行业头条

DDD领域模型设计数据中台落地——苏宁供应链域数据中台构建实践_架构_胥磊_InfoQ精选文章