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 领域建模的一些概念也可能存在偏差。“先开枪后瞄准”至少我们在探索数据中台的领域迈出了坚实的第一步，未来是康庄大道还是遍地荆棘已经不重要了，迈出了这第一步，其实成功就离我们不远了。