数据架构主题域划分跟业务域一一对应，是对的吗？

方式一

主题域与业务域1:1对应

方式二

主题域按数据自身视角划分

这种方式，它的好处是解决了不同主题域下业务对象重复定义的问题；但它的问题是，太难了！

首先，谁来做？谁有跨业务领域的全局视角、同时又具备面向对象的抽象能力；其次，怎么证明完整性，谁能背书说这些业务对象就是全的？除非，业界有相对成熟的参考模型，例如早些年，IBM、Teradata都有金融行业的主题域模型，包括参与方、合约、条件、产品、地点、事件等主题域，这也是为什么银行、保险这些企业更倾向于按这种方式定义数据主题域，而其他行业却很难做到。

看完它们各自的优缺点，我们再回过头来想想刚开始的那个问题，按业务域划分主题域是对的吗？我觉得，很难用对、错来评价，关键是你要先想清楚你做数据架构的目的是什么？

如果做数据架构是想要明确业务对数据的管理责任，提升数据质量，那的确可以按业务域来划分主题域，二者一一对应；如果做数据架构的目的是为了建立业务与IT之间的桥梁，围绕数据构建组件化、服务化的应用架构，支持灵活的数据分析需求，那你就需要从各个业务域跳出来，真正围绕企业中关键的人、事、物去构建你的主题域，在每个主题域里面识别业务对象、以及业务对象之间“谁是谁的一类”、“谁是谁的一部分”这些关系，构建一套真正的企业级的语义网络。

有时候，大家会陷入一种被方法论“绑架”的境地，就是在还没搞清楚什么是业务对象的情况下，就机械地按照三步法、五步法，再加一套excel模板，按业务域分工，让业务人员分别去设计各业务域的数据架构。本来是要做抽象的数据设计，结果变成了按模板交作业，有些人甚至会认为如果模板里填的内容太少，会显得自己的工作没有价值，那就多填一些。结果花了大半年时间，收集了几十个excel文件，里面所谓的业务对象，相互之间存在大量重叠，完全没有抽象的痕迹，连数字世界的大门都还没进去。我把这种做法称为“甩锅式的数据架构梳理”，这样做出来的数据架构可以说是没有任何价值的。