工业数据智能之基石——领域数据模型

来源: | 作者:pmod6d781 | 发布时间: 2023-04-12 | 2245 次浏览 | 分享到:

Q3：做业务解析和数据探索的匹配到底有没有必要性？

我们在数据理解阶段，就已经有意无意在梳理业务流程。比如生产制造领域，先理解工序，每一步都做了什么动作，大概是什么原理，过程中有非常多专业壁垒。再结合到每个工厂现场，还有特定的一些管理流程和管理特色。工序和管理流程交融到一起，往往会让数据很难理解。但是为什么非要费很大劲去理解这些东西呢？因为这些业务流程是那些数据产生的上下文。

某种程度上讲，数据不是我们的研究对象，其实我们研究的是数据背后相关的，比如设备、产线、生产过程甚至是操作的人，而数据是这些信息的载体，所以看数据其实是要透过数据，对相关的研究对象构建模型。

在这个行业从业多年的专家去看这些数据的时候，也要基于一些专业认知和上下文。但设备、工艺、排产和安全、环保，不同的人可能是从不同的角度去看。

当一个问题发生了，到底是属于哪一类问题，是什么原因导致的？哪怕是这个行业里的专家，也不可能面面俱到，什么因素都能穷举。且不同专业壁垒造成的隔离性比想象中更严重，不同领域的专家看同一套数据的方式和视角完全不同。

将数据基于不同的专业认知进行组合和关联，形成对物理对象的完整认知，是培养企业内部数据创新的基石。工业数字化的终极目标是全局优化。将集体智慧的专业认知基于数据进行重新融合的过程，就是领域数据建模。

Q4：领域数据建模的起源与技术思想是什么？

领域数据是结合了工业行业的特定业务背景和业务知识的数据集，后续的数据价值挖掘和应用都以此为基础去展开。

领域模型一词不是起源于数据工程领域或者数据分析领域，而是起源于Eric Evans讲程序设计的书——《领域驱动设计》，其核心思想是使用共同业务语言构建开发者和业务专家之间的桥梁，并且让软件代码直观的表达业务逻辑，使得软件系统更加可维护、可理解、可扩展。

在领域驱动设计之前，很多程序员会陷入一个写程序的误区。比如要实现一个功能，他马上就会想到数据库表，先把表建出来，然后写很多handler来处理业务逻辑，再写一个很长的sql来体现业务逻辑。后面一旦需求变了，业务逻辑变了，通常他会把sql改一下。这种就叫做database加script编程模式。这种程序会非常难于理解，难以维护。因为很多业务逻辑隐藏在了那个可以执行但是一点儿表达力也没有的“贫血模型”里。

而领域模型是跟它相对的，它提倡使用程序设计的一些基本元素，比如实体对象，通过它的结构、标准的属性和命名，它的运行方法以及方法里简单直接的代码等等，把我想表达的业务规则直观呈现出来，而不是依赖于一些特定的数据库技术或者中间件。