再以煤矿综采系统为例，采煤机和支架要相互配合。首先将基本的运行过程做工况切分，每个循环过程下，采煤机有它自己的一套动作流程和一个周期的数据，支架又有它自己的周期数据，这两个结构之间相互配合，所以采煤机的周期和支架周期之间有一定的关联关系。在这个结构之上，再提取出支架在每个循环里面做了什么，跟采煤机配合做了什么，采煤机的特定动作跟支架的动作之间建立一个关联关系，就能够看出两者的配合关系。在这里案例里，领域模型就是从业务上描述数据，再从数据还原业务基本单元和单元之间协同关系的结构。
有些人拿着领域模型去写支撑这个业务动作过程的代码和系统，就是信息化系统；我们拿着业务模型去做数据挖掘，就是领域驱动的数据模型。
Q8：如果不计较技术实现难度，从数据价值挖掘的角度来畅想一下，一个好的领域模型应该能达成什么目标？
从分析的角度来说，我们希望通过用业务语言描述的方式拿到想要的数据，例如今天第几个加工周期里面设备的温度、电压和电流，它们之间的相关关系数据，然后平台就能把这个数据集给返回来，包含三列数据，一个叫温度、一个叫电压、一个叫电流。
现在一般要从数据库的那些表里取数据，过程有时候会很繁琐，也不那么直观，会花很多时间。在数据治理、数据工程建设中，还有很多工作可以完善。有时候，很多企业计划搭建一个数据系统，技术服务商会突出底层提供什么增删改查的功能，支持哪些通用的数据库。但其实都回避了或忽视了，针对特定行业、特定产线、特定设备、特定的工业对象，怎么去构建数据模型呢？这导致后续的数据价值挖掘工作非常难以开展。
假设设备坏了，不要告诉我这个平台的数据质量、数据完整度，我就想知道这个设备它发生故障前后有没有运行数据，有没有振动数据？这个设备有以前没有发生过类似的故障？当时是什么情况？当时是谁修的，用的什么件儿？那批件儿当有没有用到其他设备上去？其他的维修率有多高……这些是我们去研究一个对象，面向良率、故障、异常去做数据分析的时候，希望看到的。我们希望数据是按照这样的方式去组织，这也是今天讲的领域模型背后表达的实质。
当然，这是一个循序渐进的过程，技术手段实践可以由浅入深的去做。首先在领域模型概念层面达成共识，才能够在今天的基础之上无限去逼近刚才提到的愿景。
