★ FEATURED ARTICLE 做数据仓库这些年只要聊到企业级数据模型几乎绕不开一个名字FS-LDM。全称是金融服务逻辑数据模型Financial Services Logical Data Model在很多资料里也常被记录为NCR FS-LDM。初次接触这套模型的人很容易被它庞大的实体数量吓到但大多数项目真正卡住的环节反而不是实体设计而是最上面那一层——主题域怎么划分。主题域划分听起来就是个分组归类实际做起来却特别容易跑偏要么照搬公司系统的模块结构要么把应用主题当成业务主题要么在十个主题域之间来回纠结。这篇文章我会结合自己在企业级数据仓库建设中使用FS-LDM框架做主题域划分的实操经验把这层东西拆开讲清楚主题域到底在模型里扮演什么角色、FS-LDM的十大主题域是怎么划分出来的、落到你自己的项目里该按什么步骤操作、以及哪些坑我踩过之后建议你绕着走。适合数仓工程师、数据架构师、数据治理岗位的同事参考。1. 主题域为什么存在它解决的是数据组织方式问题1.1 几十套系统各说各话才是主题域出现的真正原因一家中大型金融机构跑着上百套系统很正常。核心系统里有客户信息信贷系统里有借款人、担保人渠道系统里有交易流水财务系统里有科目余额。这些系统各自设计表结构、各自定义字段、各自维护口径看起来都离不开“客户”“交易”“产品”但真要跨系统分析的时候你会发现同一个客户在三套系统里是三套编码同一个“贷款余额”可以算出三个结果。主题域的价值就是在这一团乱麻里先立一个骨架。它不管表名怎么起、字段怎么设计、数据库怎么存储只管一个问题一类数据在业务概念上属于什么。客户表、借款人表、担保人表在概念上都指向参与业务的人所以归到“当事人”域柜面交易流水、手机银行流水、第三方支付流水都是业务行为的事实记录所以归到“事件”域。这个“先定义业务概念再谈表结构”的顺序恰恰是很多团队容易反着来的地方。不少项目一启动就打开数据库看物理表然后按系统模块把表分成“客户域”“交易域”“报表域”这套做法做出来的模型本质上是原系统的影子换一个数据源系统就得改一遍模型等于没建模型。1.2 FS-LDM为什么能成为业界参考标准FS-LDM之所以被反复提及核心原因是它几乎没有绑定任何一家企业的系统差异。它站在银行、保险、证券这类金融服务行业共有的业务概念上把数据组织成一套可复用、可裁剪的逻辑框架。行业里大量数据仓库项目以它为蓝本做过定制后来做数据中台、做监管数据集市也常常回头参考它的主题域划分思路。FS-LDM对企业级数据建模最重要的贡献就是给了你一套现成的、经过大量实践验证的“数据地图”。你不需要从零开始发明主题域也不用自己拍脑袋决定某个实体该放哪而是先理解这套地图的逻辑再按自己企业的业务范围做裁剪和调整。主题域边界定准了后续实体设计、关系设计、物理表映射全部会顺着这个框架走事半功倍。1.3 主题域不等于系统模块也不等于应用主题我见过不少团队把“客户管理”“贷款管理”“风控报表”当成主题域。这些词听起来很像主题实际却分属另外两个层面系统模块描述的是“功能从哪里来”客户管理系统、贷款核心系统这些是功能边界应用主题描述的是“数据给谁用”风控报表、经营分析看板是使用场景而主题域描述的是“数据本身是什么”不管数据从哪个系统来、给哪个报表用它在业务概念上就是当事人、就是协议、就是事件。主题域、系统模块、应用主题三者混在一起模型就会变得既不像业务模型也不像应用模型。判断方法很简单如果这个分组换个系统、换个报表依然成立它才有资格当主题域如果它的存在依赖于某个特定系统或特定报表那它只是应用层的分类。这个标准建议在建模启动会的时候就讲清楚能省掉后面无数场争论。2. 三层建模结构中主题域到底被定义在哪一层2.1 概念模型层给业务专家看的那张“地图”企业级数据模型通常分概念模型、逻辑模型、物理模型三层。概念模型是最精简的一层画出来一般就是一张图十个主题域每个主题域下放几个核心实体实体之间画几条关系线。这一层的目标不是建模而是沟通——让业务专家在不需要理解任何技术细节的前提下确认“我们公司的数据大致分为这几个板块”。概念模型层虽然简单但主题域的边界恰恰是在这一层讨论定稿的。很多项目在这一层草草画一张图就算完直接跳到物理表设计这等于地基没夯实就盖楼。主题域的命名、个数、边界必须在这一层和业务专家逐项对齐一旦确认后面逻辑模型和物理模型都要严格遵守。2.2 逻辑模型层主题域划分真正的主战场逻辑模型层是FS-LDM真正值钱的地方。这一层在每个主题域内部把实体、属性、关系按第三范式逐步细化例如“当事人”域下面会有自然人、法人、机构内部人员等实体以及他们之间的关联关系“协议”域下面会有存款协议、贷款协议、担保协议等。到了这一层数据的业务含义已经完整固化物理表再怎么调整逻辑模型都保持不变。实际操作中很多团队为了赶工期从概念模型直接跳到物理建表逻辑模型被彻底跳过。后果就是主题域只剩一个表名前缀或schema名实体关系、属性口径全丢模型退化成一套命名规范FS-LDM里沉淀的业务经验一点都没用上。如果你希望模型能长期使用逻辑模型这层不能省哪怕裁剪也要留下一套完整的、带属性定义和关系说明的逻辑模型文档。2.3 物理模型层主题域如何“翻译”进数据库物理模型层解决的是性能与存储问题包括表结构、索引、分区、存储策略等。在物理层主题域通常体现为库或schema的划分比如数据仓库的DWD层按主题域组织表每张表归属一个主题域前缀或schema。这里有一个实践建议可以允许跨主题域的宽表、汇总表存在尤其是支撑报表和指标计算的汇总表但它们的“所属主题域”仍按主业务对象归类不要另立山头。更需要注意的是绝对不要拿物理表反推主题域归属。物理表为了性能会有冗余、有反范式设计、有快照表、有汇总表一张宽表里可能既有客户信息又有协议信息如果你从物理表出发定义主题域模型会被性能和存储带偏越推越乱。正确的顺序永远是先有逻辑层的主题域划分再有物理层的表归属。3. FS-LDM十大主题域的划分逻辑与边界判定3.1 十个主题域的全景视图不同版本资料的FS-LDM主题域名可能略有差异但划分思想一脉相承。我按自己在项目里常用的一套中文命名把最核心的十个主题域整理成一张表方便对照主题域职责定位典型实体举例当事人业务参与者包括自然人、法人、机构内部人员客户、借款人、担保人、内部行员产品可售卖的金融服务与业务产品的定义存款产品、贷款产品、产品定价规则协议当事人之间形成的具体契约关系存款合同、贷款合同、担保合同事件业务行为与业务过程的事实记录交易流水、还款事件、利息计提事件资产被用于抵质押或形成价值的资产抵押房产、质押股权、抵债资产财务账务处理与会计核算相关数据科目余额、内部账、损益记录区域业务发生的地理位置与组织区域网点、分支机构、省市区地址渠道业务触点和交易发生的途径柜面、网银、手机银行、自助设备营销活动营销活动定义及活动参与信息活动名单、活动响应记录、权益发放通用以上主题域都不归属的通用数据公共代码、汇率、节假日表这张表看上去简单但每个主题域的粒度定义需要格外注意。比如“事件”域它包含的是业务行为发生的事实记录强调的是“发生了什么”而“财务”域包含的是账务处理与核算结果强调的是“账上怎么记”。“事件”先发生“财务”后入账两者是顺序关系边界不能混。3.2 用一笔贷款拉通所有主题域十个主题域听起来抽象用一个具体业务串一遍就直观了。假设客户张三申请一笔个人消费贷款张三这个人进入“当事人”域他的客户信息、身份信息都在这里沉淀。他申请的“等额本息个人消费贷”产品是银行可售卖的标准化产品定义进入“产品”域。审批通过后张三签了借款合同合同编号、额度、利率、期限这些具体契约内容进入“协议”域。银行放款、张三按月还款每一笔放款和还款动作产生的事实记录进入“事件”域。张三用于抵押的房产进入“资产”域。银行按合同计提利息、确认收入相关科目记录进入“财务”域。这笔贷款在某个城市的某个支行办理涉及“区域”域如果张三是通过手机银行自助申请的还涉及“渠道”域如果张三是因为某个营销活动被客户经理拓展来的还会关联“营销活动”域。一笔贷款业务牵动九个主题域。这说明主题域划分不是按业务流程切段而是按业务对象聚类。同一个业务事实会被拆到多个主题域里主题域之间的实体关系自然形成跨域的虚线连接这是模型设计的正常形态。3.3 三组高频边界判定原则主题域划分最常见的问题是边界模糊我列举三组高频判断场景。第一组协议 vs 产品。判断标准是“有没有具体的合同编号、有没有当事人双方关系”。有具体合同编号、有借贷关系的真实契约是协议只是产品模板、利率定价规则、期限选项属于产品定义。简而言之签了字的进协议域挂在价目表上的进产品域。第二组事件 vs 财务。判断标准是“是业务事实还是记账结果”。交易发生了但没有入账流水记录是事件入账后的科目余额、损益记录是财务。当然FS-LDM里“事件”也可能影响“财务”但在归属上不能既是事件又是财务项目里必须定死这个原则。第三组当事人 vs 协议。当事人是“参与业务的角色”协议是“角色之间的关系契约”。张三这个人本身永远在当事人域他和银行之间的借款契约在协议域。不要因为某个实体和协议强相关就把它扔进协议域身份数据和契约数据要分开管。边界判定没有绝对唯一的答案但一个团队必须有一套统一的判定原则并且写进建模规范。遇到争议实体时建模负责人要拍板不要追求所有业务线完全一致只要数据字典里留下归属理由后续变更就有据可查。4. 从FS-LDM到自有模型主题域划分的实际落地步骤4.1 六步走把主题域从纸面落到项目里第一步圈定业务范围。明确本次建模覆盖哪些业务条线、涉及哪些系统清单先划定边界再谈划分。没有边界框架的主题域划分最后一定会失控。第二步识别核心业务事件。从事件出发做梳理开户、存款、取款、申请贷款、还款、核销、结转……把业务事件清单列出来。事件是业务发生的锚点围绕事件去反推需要哪些当事人、产品、协议数据自然比凭空想主题域要高效。第三步抽取实体并命名。这一层最容易犯的错是直接用系统表名当实体名比如把“客户信息表”写成“CIF_TABLE”。正确做法是用业务名词命名例如“法人客户”“自然客户”“担保人”实体名要让人不看表结构也能理解业务含义。第四步归并到主题域。用FS-LDM的十大主题域做初步归类。归类过程中经常发现两个实体其实描述同一个对象需要在域内做合并这是逻辑模型层最耗精力的环节。第五步评审对齐。和业务专家、各系统数据负责人逐域确认边界。评审不是为了走流程而是把“当事人域和协议域的边界是否清晰”“客户和担保人到底算一个实体还是两个实体”这类问题彻底敲定。第六步形成逻辑模型并映射物理。整理实体关系图、属性字典、关系说明形成开发规范。逻辑模型评审通过后物理表和ETL开发才有依据。4.2 不是每家企业都需要十个主题域很多团队看到十大主题域就发愁担心自己企业体量撑不起这么完整的框架。实际上FS-LDM本来就是可裁剪的。一家没有资金交易业务的城市商业银行完全可以不建独立的财务域只在事件域和协议域里保留必要的账务参考属性一家渠道单一的小型机构可以把渠道和营销活动合并成一个域。反过来大型集团和同业业务机构往往还需要把某个主题域进一步拆细比如财务域下再分“总账”“分户账”“损益”等子主题域。裁剪原则只有一条裁剪的是范围子集不是另起炉灶。FS-LDM里的标准命名、实体关系、属性定义能做参考的尽量保留否则又会退化成每家一套方言的乱局。4.3 主题域名和编码规范看着小事坑最深主题域名称建议用业务短语不要用系统缩写。我遇到过一个真实案例某公司的主题域名直接用系统代号命名后来源系统下线整个主题域没人知道对应什么业务模型文档几乎作废重建成本极高。编码规范建议尽早定下来。主题域可以用两位或三位英文编码加中文名例如PTY表示当事人、AGR表示协议、EVT表示事件。实体命名遵循主题域编码加实体英文名的格式全公司统一。这个规范越早定后面数据资产目录、指标血缘、数据权限管理都会省力很多。4.4 评审会议不要开成“辩论赛”要有标准问题清单我参加过不少主题域评审会低效的会都有一个共同特征没有判定标准全靠个人感觉。后来我习惯用一组标准问题来引导评审效果立竿见影这条数据描述的对象是谁是“参与业务的角色”还是“角色之间形成的契约”它是业务发生的事实记录还是业务发生后形成的账务结果它是可以批量售卖的模板还是已经和客户签订的具体合同换一个系统来看这条数据还应该属于同一个主题域吗这四个问题基本能覆盖九成以上的边界争议。对于剩下的争议实体用“建模负责人拍板 数据字典记录归属理由”的方式处理比没完没了开会更务实。主题域划分的最终目标不是让每个业务部门都满意而是让全公司有一份统一、稳定的数据语言。5. 主题域划分完之后还要接上数据资产和治理的最后一公里5.1 数据资产目录要以主题域为一级骨架主题域划分完成画完图不是终点它应该成为数据资产目录的一级分类。规范的资产目录层级是主题域、业务数据对象、实体、属性。用户找数据时最先问的是“我要看客户、协议还是事件”而不是“我要看哪张表”所以主题域作为入口最自然。我在项目里通常这样组织一个主题域对应资产目录的一个一级节点其下先列业务数据对象再展开实体的属性清单。属性要做到一一映射到物理表字段这样数据地图、数据检索、数据权限申请都能挂在这套结构上资产目录才真正可运营。5.2 指标落地要有主题域归属不能挂在报表上指标字典建设经常犯一个错指标挂在报表下面报表下线指标就失联。正确做法是把指标挂在主题域下。比如“存款余额”是协议域指标“不良贷款率”是协议域或资产域指标“客户流失率”是当事人域指标。主题域是稳定的报表会不停变化指标挂在主题域下即使支撑它的报表下线了指标的组织位置也不会消失。做指标血缘分析时主题域层面的归属也能快速圈定影响范围。某个主题域的数据质量出问题能直接回溯到哪些指标、哪些报表受影响治理效率会明显提升。5.3 每个主题域都要有数据owner模型才不会烂尾主题域划分得再漂亮没有数据owner就等于没人负责。数据owner虽然更多是治理范畴的事但建议在建模启动阶段就把每个主题域对应的责任人岗位列进责任矩阵。当事人域的数据owner要管客户身份要素质量协议域的数据owner要管金额、利率、期限准确性事件域的数据owner要管流水完整性。数据质量规则也建议按主题域配置。你不可能给几千张表逐张配质量规则但你可以给每个主题域配置一套核心质量规则再下钻到关键实体和关键属性的技术规则。一个主题域的质量分出来了整个域的数据健康度也就有数了。5.4 主题域层面的变更管理要克制主题域级变更属于企业级模型的重型变更不能频繁发生。我的实践经验是三个月内不要随便加域至少半年做一次整体评审。日常新增实体时先尝试放入已有主题域确实找不到归属再考虑开新域而开新域必须经过数据治理层面的评审。另外我习惯保留“通用”域作为临时存放区但要求每季度清空一次。这样做的好处是建模过程中暂时无法判定归属的实体可以先放进去不阻塞开发进度同时强制性地每个季度清理一次防止它变成谁也不管的垃圾桶。主题域框架的稳定性是靠这种“能不开新域就不开新域”的克制维持的。最后说点个人体会。我用FS-LDM做主题域划分前后经历过好几个项目最大的感受是画一张主题域全局图最多一周时间真正耗时间的是让所有团队对边界达成一致。有些团队一开始想“一次到位”把所有域全部细化到实体评审会开了两个月大家越吵越细后来改成先定六个核心域跑通数据链路后再扩展财务、区域这些辅助域反而顺利得多。如果你正准备在自己公司推主题域模型我建议优先从事件域开始梳理。事件是业务发生的锚点把事件域理清了当事人、产品、协议、渠道、财务这些域会自动围着它转主题域之间的跨域关系也会自然浮现。主题域不是画出来的是一轮一轮业务对齐全出来的——这句话我用了很多年希望对你也有用。
阅读完成 · 觉得有帮助？
