业务架构与数据架构的联动设计方法：从业务域映射到数据域的完整路径

Tue, 20 Oct 2026 09:00:00 +0800

做过架构规划的人大概都遇到过一个场面：业务架构图挂在会议室墙上，数据架构图躺在数据团队的文档库里，两张图各自都画得挺漂亮，但没人能把它们叠在一起看。

问业务部门"你们的客户域包含哪些业务能力"，答得清楚。问数据团队"客户主题域覆盖哪些实体"，也答得清楚。再追问一句"这两个域是不是同一件事"，两边都沉默了。

这就是联动断掉了。它不是文档问题，是设计方法问题——大部分企业的业务架构和数据架构是两条独立的产线，一条交给咨询顾问画价值流，一条交给数据团队做建模，中间没有交接规程，也没有共同的锚点。结果就是各画各的，各自自洽，互相不认识。

下面这条路径，是把两件事接起来的可执行方法。

一、先认清断链的四种症状

在给方法之前先确认问题长什么样。联动失效通常有四种表现，越往后修复成本越高。

症状	现场表现	根因
域不对齐	业务域划了 12 个，数据主题域划了 18 个，谁也说不清对应关系	两套划分各按各的逻辑做，中间没有映射表
实体无主	同一个"客户"在 4 个系统里各存一份，字段口径全不同	没有权威源认定，缺乏写入归责
规则脱节	业务规则写在制度文件里，数据侧没有任何对应的校验	业务规则从未下沉为数据规则
变更失联	业务流程改了三个月，数据模型才发现对不上	缺少变更联动的触发机制

前两种是设计缺陷，一次补齐就能解决；后两种是机制缺陷，得靠长期运转。很多企业做完一轮架构规划就以为收工了，其实补齐设计只完成了一半——没有人持续维护的映射表，半年后一定烂掉。

二、联动的锚点不是文档，是"域"

业务架构和数据架构之间最容易建立的共同语言，是"域"这个概念。但两边的域不是同一种东西，这是分歧的源头。

业务域是组织与责任的边界，回答"谁负责创造这段价值"。它跟着价值链走，稳定性高，一个域通常对应一个能端到端交付结果的团队。

数据域是实体与语义的边界，回答"这个业务对象由谁定义、在哪里产生、如何被信任"。它跟着实体走，一个主题域会横跨多个业务域。

强行让业务域和数据域 1:1 对齐，是最常见的错误。销售域和售后域都需要客户实体，客户主题域必须被两个业务域共享——这就是 N:1 关系，不是设计失误，是客观事实。

业务域怎么划才稳定

四条准则，按顺序检查：

按价值链切，不按组织架构切。 部门会重组，价值链相对稳定。按部门划出来的域，一次组织调整就得重画。
一个域必须能端到端交付一个可度量的结果。 交付不了结果的是能力，不是域。
域内高耦合、域间低交互。 两个域之间如果每天要同步十次状态，它们大概率该合成一个域。
总数控制在 8 到 15 个。 超过 15 个，一线没人记得住，映射表也就没人维护了。

一家整车企业的业务域大致长这样：研发、采购、制造、质量、销售、售后、财务、人力，八个。这个数量级的好处是全公司一张纸能画完，讨论时不会因为域本身没共识而跑偏。

数据主题域的三种切法

数据侧常见的划法有三种，各有适用场景：

按业务对象聚类（客户、产品、物料、供应商、车辆、订单、工单、财务科目）——最常见，实体边界清晰，适合做主数据治理。
复制业务域结构——看起来对齐成本最低，实际上会制造大量跨域重复实体，只在业务域极其稳定时可用。
按数据分层切（主数据、事务数据、参考数据）——适合数据平台建设，但不适合做架构联动，因为它不表达业务语义。

推荐组合：主题域为主结构，业务域做索引标签。每个主题域标注它主要服务的业务域，一个主题域可以挂多个标签。这样既保留了实体的完整性，又能从业务视角反查。

三、四层穿透：从业务域走到数据域

有了两边的域，接下来是逐层穿透。四层，每层都有明确产出物。

第一层：业务域 → 数据主题域

产出「域映射表」，解决"哪个业务活动产生哪类数据"的问题。

业务域	主要数据主题域	映射类型	关键实体
研发	产品、物料	1:N	车型配置、零部件、BOM
采购	供应商、物料	1:N	供应商主档、采购协议
制造	车辆、工单	1:N	车架号、生产工单、工序记录
销售	客户、订单	N:1	客户主档、销售订单
售后	客户、车辆、工单	N:1	客户主档、维修工单

这张表的价值在于暴露共享。看到客户主题域同时出现在销售域和售后域，就必然要问：谁是权威源？谁负责质量？这个问题在业务架构里永远不会被提出来，但它恰恰是数据治理最痛的地方。

第二层：业务流程 → 实体生命周期

第一层只解决了"有没有"，第二层解决"什么时候"。每个关键业务活动，都要标注它在实体生命周期上的位置：创建、变更、失效。

以客户实体为例：

生命周期节点	触发业务活动	所属业务域	关键字段
创建	线索转化为商机客户	销售	客户名称、证件号、联系方式
变更	签约时补充开票信息	销售	税号、开户行、账期
变更	售后受理时补充联系人	售后	服务联系人、地址
失效	连续 24 个月无交易且主动注销	销售	状态、注销原因

把这张表拉出来，很多长期悬而未决的争议会自动收敛。比如"客户地址以哪个系统为准"——看生命周期表就知道，签约环节的地址是法定地址，售后环节的地址是服务地址，两个字段本来就该分开建模，而不是争论谁覆盖谁。

第三层：业务能力 → 数据资产与指标

业务架构里通常有业务能力地图，数据侧有指标体系和数据资产目录。这一层的映射回答"这个能力靠什么数据支撑、又沉淀出什么数据"。

业务能力	依赖数据	产出的数据资产	核心指标
产销协同	订单、产能、库存	产销平衡表	订单交付准时率
供应商绩效评价	采购订单、到货记录、质检结果	供应商评分模型	来料合格率、交付及时率
整车质量追溯	车架号、工序记录、零部件批次	单车质量档案	单车故障率、批次召回范围

这一层做完，指标口径的争议会少一大半。因为每个指标都能追溯到具体的能力和数据源，“这个数为什么和财务口径不一样"变成一个有答案的问题，而不是互相指责。

第四层：业务规则 → 数据规则

最容易被跳过、也最容易翻车的一层。制度文件里的规则如果不翻译成数据侧能执行的约束，就是纸面规则。

业务规则（制度语言）	数据规则（可执行）	落点
供应商准入须完成资质审核	供应商主档状态流转必须校验资质附件	主数据系统状态机
采购订单金额超阈值需两级审批	订单金额 > 阈值时 approval_level ≥ 2 才允许提交	订单表约束 + 审批流
车架号一车一码，不可重复	车架号字段唯一索引，且长度/校验位合规	车辆表 + 接口校验
客户开票信息变更需留痕	开票字段变更写审计表，含操作人/时间/前后值	审计表 + 变更触发器

翻译过程本身就是一次规则体检。很多业务规则写得含糊（“必要时"“原则上”），一旦要翻译成 if 判断就原形毕露——这些含糊规则正是数据质量问题的源头。

四、用 CRUD 矩阵定权威源

四层映射做完，还有最关键的一步：每个实体必须只有一个权威源。这件事口头讨论永远讨论不完，必须上矩阵。

矩阵的行是业务活动，列是数据实体，格子里填 C（创建）、R（读）、U（更新）、D（删除）。规则只有四条：

唯一的 C 者即权威源。 只有它有权创建，也只有它承担数据质量责任。
出现多个 C，必须处理。 要么拆实体（法定地址 vs 服务地址），要么定主从（一方创建、一方只读同步）。
只 R 的系统是消费方。 不承担质量责任，但要承担口径一致性责任——它得用权威源的口径。
U 权限必须单独约束。 非权威源系统不得直接改写核心字段，只能提变更请求。

一张简化的客户实体矩阵：

业务活动	客户主档	客户地址	开票信息	联系人
线索转化	C	C	—	R
合同签约	U	U	C	R
售后受理	R	U（服务地址）	R	C
财务开票	R	R	R	R
客户服务系统	R	R	R	U

盯着"客户地址"这一列看：线索和签约都在 C/U，售后也在 U。三个写入口，这就是数据打架的源头。处理办法不是开会吵架，是把地址拆成"注册地址"和"服务地址"两个实体，各自有唯一 C 者。

CRUD 矩阵真正的价值不是那张表，而是填表过程中被迫暴露出来的多重写入。很多企业填完第一版才发现，同一个核心实体有三到五个系统在写，而之前所有人都以为"只有一个系统在维护”。

五、让联动长期跑起来的三件事

方法和表都是静态的，不设计机制，三个月后一定退化。三件事必须固化到流程里。

1. 一张主表

架构联动清单，一行一个"业务域—主题域—主实体"组合，字段固定：业务域、数据主题域、主实体、权威源系统、业务责任人、数据责任人、关键指标、最近评审日期。

这张表就是联动的唯一事实来源。所有架构讨论以它为准，不认口头说法。

2. 一个评审口

架构评审会必须业务架构师和数据架构师同时在场，缺一不批。

这条看起来是行政规定，实际是最有效的机制设计。它把"数据影响"从可选项变成了强制项——任何业务架构变更在评审时，如果数据侧说不出受影响的实体和系统，评审就不通过。

3. 一条变更流

业务流程变更单上增加一个必填字段：数据影响评估。

内容包括：涉及哪些实体、哪些系统需要改、历史数据是否需要迁移、指标口径是否变化。不做评估不得上线。

这条流程会在最初几个月制造大量摩擦，业务方会抱怨"改个审批节点也要填表”。但只要坚持过一个季度，评估内容会越来越薄——因为大部分变更确实没有数据影响，表态"无影响"只需要三十秒。真正的价值在于那少数有影响的变更被拦住了。

六、分三阶段落地

不要一次全面铺开，选两三个最痛的域先做透。

第 1—4 周：域对齐。 盘点现有业务域与数据主题域，产出域映射表 v0.1。这一版只求覆盖、不求精确，允许标注"待确认"。目标是让两边第一次看到对方的全貌。

第 5—8 周：权威源认定。 挑两个数据争议最大的域（通常是客户和物料），做完整的 CRUD 矩阵，认定权威源，把多重写入的问题定性。这一步产出的不是文档，是待整改清单。

第 9—12 周：规则下沉与机制上线。 把关键业务规则翻译成数据规则并落到系统约束上，同时把评审口和变更流写进流程文件，指定责任人。机制不上线，前面所有产出都是临时的。

七、四个指标检验联动质量

联动做得好不好，不看文档厚度，看四个数：

指标	定义	参考目标
域映射覆盖率	有明确映射的业务域 / 业务域总数	100%
权威源认定率	已认定唯一权威源的主实体 / 主实体总数	首年 ≥ 70%
规则一致率	有对应数据规则的关键业务规则 / 关键业务规则总数	≥ 80%
变更联动及时率	业务流程变更后 10 个工作日内完成数据侧同步的比例	≥ 90%

前两个衡量设计完成度，后两个衡量机制有效性。只报前两个的团队，通常第二年就会发现映射表已经没人看了。

八、三个容易踩的坑

把业务架构当输入、数据架构当输出。 正确的做法是双向的：数据侧发现某类实体缺失，应该反向推动业务架构补充对应能力。单向流动的联动，数据架构永远是被动的翻译层，也就永远慢半拍。

追求全域一次到位。 十二个业务域同时做 CRUD 矩阵，结果一定是每张表都填了一半。两三个域做透，形成可复制的模板，比全面铺开有效得多。

把映射表当成交付物。 映射表是活的，每季度必须刷新，每次架构变更必须更新。没有评审日期和责任人这两列的表，本质上是一次性文档，写的时候就已经过期了。

业务架构和数据架构能不能叠在一起看，是判断架构工作是否真正完成的标准。两张图各自漂亮但互不相认，说明做的还是两件事；只有业务域的每一次调整都能立刻说出数据侧的影响，数据侧的每一次建模都能追溯到具体的业务能力，架构才真正落在了同一个企业上。

业务域 on 文艺技术笔记