【软件架构系列1-本体】本体架构在软件体系结构中的角色定位

伴随着本体论应运而生的“本体架构”，在现有的软件体系结构中处于什么角色，与其它架构怎么协同。

本次咱们一起聊聊：本体架构没有顶替任何一张现有架构图，它新增的核心，就是业务架构和数据架构之间这层语义。

一、先说一下背景：信息系统，天生围着数据转

《持续架构》关于数据有这样的表述：信息系统是为处理数据而存在的，迄今为止开发的每项技术的目的，都是为了保证更高效地处理数据，任何软件系统都需要以数据为中心来考虑基本架构。

数据怎么升级成智慧，我们用DIKW金字塔来画，自底向上依次是：数据-》信息-》知识-》智慧。

可问题在于：处理数据只是前提，不等于处理完了就懂业务。数据在库里躺着，系统在跑着，但“这条数据到底意味着什么、这两条数据能不能放在一起比”，得有一层东西去解释。这一层，正是本体的核心价值。

二、一句话讲清楚本体在架构图体系中的定位

把三张架构图并排摆开，分工就清晰了。业务架构定义业务世界有什么、做什么、规则是什么；本体架构是业务架构的机器可读、可推理语义投影；数据架构定义业务事实怎么存储、清洗、流转、落地。

本体正好处于业务架构与数据架构之间，是一个独立的“知识语义架构层”。它不属于传统架构域，既不算业务架构，也不算数据架构，而是独立的一层。

三、三层怎么分工协作：业务面向人，本体面向机器，数据面向存储

先看职责边界。

业务架构面向人，解决业务定义、流程、能力、业务规则，产出是业务流程图、业务词典和自然语言业务规则。它的短板也很明确：存在歧义，没法机器推理，没有严格逻辑公理。

本体架构（TBox+ABox）面向机器语义与逻辑，把业务规则形式化。TBox管类、继承、属性、关系以及OWL公理（传递、互斥、基数约束）；ABox存业务实例事实和推理派生事实。它独立于数据库、可跨系统融合、支持自动推理。

数据架构面向数据落地存储，解决数据怎么存、怎么管、怎么加工。往下再拆，就是大家熟悉的CDM（概念数据模型，面向业务）、LDM（逻辑数据模型，面向数据架构师）、PDM（物理数据模型，绑定具体数据库）。

三层之间驱动关系环环相扣：

•自上而下，业务架构先定规则，再经本体语义建模，最后驱动数据建模落地；

•自下而上，存量数据暴露出问题，本体在校验中发现矛盾，反向修正业务认知；

•中间靠语义映射（Schema+Instance）把语义层和物理数据解耦，两边改动互不牵连。

这里有三个最容易踩的坑：

•本体只抽象静态概念与规则，不含流程、组织、权责。把它当业务架构，是理解偏差；

•CDM为建表服务，本体为推理与语义统一服务。把本体当CDM，功能对不上；

•本体不替代数据架构，更不替代数据库。它是在数据底座之上加一层，不是把底座换掉。

四、跟业务系统共建：两个模型，分开走，谁也别替代谁

本体要落地，离不开和业务系统配合。这里的总原则是：业务系统是权威记录系统（SOR- System of Record），本体是概念语义，它的建模思路追求业务概念无歧义、完备、可推理。二者同步建设、双模型分离、映射解耦、联合评审、互不替代。

最需要警惕的一条红线：把本体TBox直接当成业务事务数据库模型来用。事务、并发、性能会一起崩掉。事务模型和语义模型，永远是两层，逻辑分离，部分可以物理复用。

落地讲究三个铁律：

•事务模型和语义模型，永远分开两层；

•权威写入永远发生在业务系统，本体只读，不直写数据库；

•任何跨模型变更，都要三方联合评审。

五、跟大数据基础库&主题库共生：一个管数据，一个管知识

企业里通常还有大数据。基础库（DWD）贴源清洗明细事实，保留原子记录；主题库（DWS）按业务域汇总成业务专题表。它们都属于数据架构，解决的是数据怎么存、怎么治理、怎么查询。

本体属于知识架构，解决的是另一类问题：数据代表什么含义、有什么逻辑、能推导出什么。

两者的差异，都条都需要重点关注：

•规则形态：基础/主题库靠SQL硬编码和文档备注，本体是机器可执行的形式化公理；

•关系能力：基础/主题库依赖物理外键、要预计算结果，本体能对传递、层级、冲突做自动推理；

•跨源能力：基础/主题库新增一个数据源要重写关联SQL，本体只要加一条映射，公理全局复用；

•世界观：基础/主题库是封闭世界，没有记录就当作不存在；本体是开放世界，没有记录只说明未知，不等于不存在。

六、跟MDM主数据共治：一个收拾“数据乱”，一个收拾“语义乱”

主数据（MDM）和本体最容易让人分不清。换个说法就清楚了：MDM统一实例、统一ID、统一属性值，解决的是“数据乱”；本体统一概念、统一边界、统一逻辑规则，解决的是“语义乱”。

两者是协作关系。MDM主数据是ABox的事实来源；本体把MDM的LDM（Logical Data Model）实体映射成TBox的Class，把字段映射成数据属性，把实体间关联映射成对象属性，再把每一条数据记录翻译成一组三元组断言，形成ABox。

ABox里的断言分两类：

•基础事实断言，来自MDM、业务系统这些可信源，是ground truth，不能被推理篡改；

•推理导出断言，由TBox公理推出来的新事实。

数据流可拆为两条并行能力：

①数据治理链路：多业务源系统→ MDM（主数据 SOR） → 大数据主题库（只读投影，用于批量加工）；

②语义框架（前置）：业务概念→ 本体 TBox，定义映射规则、业务公理； 

消费侧：语义应用/ AI Agent 发起查询 → 基于 TBox 的映射规则，按需从 MDM / 主题库动态生成虚拟 ABox 断言，经过语义服务编排后返回结果；必要时仅将小范围子集物化 ABox 用于复杂推理（沙箱推理）。

双向赋能。正向是MDM支撑本体，给它干净、唯一、可信的实体ID和属性；反向是本体赋能MDM，帮它发现语义冲突、找出被漏治理的关联主体，还能用图特征提升MDM的查重准确率。

落地仍有一条铁律：本体绝不做实体合并、拆分、身份变更，那是MDM的专属权责；本体的ID必须基于MDM的MasterID，保证全局唯一。

七、本体治理和传统大数据治理是两种玩法

传统大数据治理以数据表、字段、记录为治理对象，业务高阶规则要么靠文档，要么靠SQL硬编码。它的短板很明显：识别不了传递关系，发现不了语义冲突，模型本身的缺陷更是难以自发现——模型就是标准，标准错了，没人知道。

本体治理换了一套基准：以真实世界业务概念、语义、公理为准。业务规则模型化之后可复用、可推理，跨数据源统一校验，不用重复开发SQL。更重要的是，它既能校验数据，也能校验数据模型本身。

一句话点透本质：传统治理问的是数据是否符合模型；本体治理问的是，数据与模型是否符合真实业务世界。

但要强调，本体治理不是来替代传统治理的。它是在清洗、权限、血缘、调度、指标这套既有能力之上，再叠加一层语义治理——统一语义、逻辑推理、冲突挖掘、知识化。

八、业务系统已经定型了，本体还能后补吗

现实里更常见的情况是：业务系统、数据库、数据模型都已经定型，历史脏数据、模型缺陷、口径混乱一并存在，又改不动业务系统。这时候要保证本体贴合真实世界，靠几条硬原则。

TBox忠于真实业务世界，不迁就历史数据库模型。数据库不过是“业务记录副本”，副本有错，本体负责发现，不负责迁就。

正确性靠四层保障兜底：

•TBox语义保真，由业务专家定义真实世界规则，不去反向工程数据库；

•映射层保真，用标准化映射规则隔离业务库缺陷，统一清洗、转换、异常标记；

•ABox实例校验，覆盖语法、语义公理、实体同一性；

•推理一致性校验，做闭环测试、冲突检测、循环关系检测、版本比对。

出了问题就按三级归因定位：TBox定义有问题，改语义模型；映射翻译有问题，改映射规则；源数据业务有问题，走工单回流业务系统去修。

九、业务说不清，谁来抽象本体

说到底，本体难不在技术，难在业务概念抽象。数据治理是整理已有的数据，本体治理是定义业务世界的规则，难度完全不在一个量级。

这件事靠一个人扛不动，需要四个角色各管一段：

•域业务首席专家，是语义立法者，负责定义概念、边界、规则、裁决冲突；

•本体架构师，是语义翻译官，把业务自然语言转成OWL公理模型；

•数据治理专家，负责衔接MDM、数据质量、工单体系；

•业务架构师，负责跨域概念协调。

落地要务实，别一上来就憋大招：不做全域大本体，只做窄域增量本体；先试点规则清晰、价值高的域，比如企业关系、主数据分类；把规则分成：可形式化、复杂例外、待收敛三类，不强求完美；能复用的行业标准本体就用，别重复造轮子。

必须承认一条底线：本体解决不了业务本身的认知混乱。业务说不清，本体一定烂尾；业务能达成共识，本体才能固化下来、可机器执行、可长效治理。

十、几种架构的融合视角 

把这几张架构图合起来看，答案就清楚了。业务架构定意图，MDM定实体身份，大数据平台定数据存储与加工，本体定业务语义与逻辑规则。四套体系各司其职、双向赋能，最终想实现的，是数据可信、语义统一、规则可执行、关系可穿透、问题可自发现、知识可智能化复用。

判断一家企业要不要上本体，先别问它热不热，先看一个信号：数据已经堆起来、系统也跑起来了，可同一件事在不同系统里口径对不上，业务规则散落在文档和SQL里，机器看不懂。这时候缺的，往往不是更多数据，而是把“业务怎么说”翻译成“机器能计算和推理”的那层语义。

九篇分篇规划：

参考书目：

1.演进式架构（Building Evolutionary Architectures）[美] 尼尔·福特（Neal Ford）、[美] 丽贝卡·帕森斯（Rebecca Parsons）、[澳] 帕特里克·柯（Patrick Kua）；第2版新增作者普拉莫德·萨达拉奇（Pramod Sadalage）

2.持续架构实践（Continuous Architecture in Practice）[美] 穆拉特·埃尔德（Murat Erder）、[美] 皮埃尔·普约尔（Pierre Pureur）、[英] 伊恩·伍兹（Eoin Woods）

3.架构师修炼之道（Design It! From Programmer to Software Architect）[美] 迈克尔·基林（Michael Keeling）

4.面向模式的软件体系结构（POSA，Pattern-Oriented Software Architecture）[德] Frank Buschmann、Regine Meunier、Hans Rohnert、[瑞士] Peter Sommerlad、[德] Michael Stal（卷1）

5.企业应用架构模式（Patterns of Enterprise Application Architecture，EAA）[英] 马丁·福勒（Martin Fowler）（David Rice、Matthew Foemmel等参与贡献）

6.整洁架构之道（Clean Architecture）[美] 罗伯特·C·马丁（Robert C. Martin，Bob大叔）

7.浮现式设计（Emergent Design：专业软件开发的演进本质）[美] Scott L. Bain（斯科特·贝恩）

8.架构思维：从程序员到CTO郭东白（美籍华人）

9.左耳听风：传奇程序员练级攻略（博文视点出版，陈皓文集）

10.架构的本质（极客时间《许式伟的架构课》）