《AI时代的集团Ontology从架构决策到产品运营》第04篇给负责人先读第一至四节、第十至十二节判断哪些资产值得共同投入。给架构师第五至九节展开身份、契约、扩展、部署及完整接入推演。甲集团、A与B制造公司、C服务板块及全部经营情节均为虚构教学设定不对应真实客户。一、一个“集团可用库存”为什么让三家公司都不满意甲集团完成了首轮准备检查决定继续验证A、B两家制造公司的供应中断处置。集团技术团队准备建立统一库存对象并请C服务板块一起提供字段。大家都希望减少重复建设讨论却很快遇到阻力。A公司希望“可用库存”扣除已预留数量并考虑用途批准。B公司提出某些预留经过授权后可以调整不能一律排除。C公司认为维修备件承担服务合同保障同样的在手数量可能根本不能进入制造调拨。财务团队又提醒账面存货价值与现场可调数量不是同一个问题。一种方案是把所有字段都放进集团对象再增加公司、业务类型和例外标识。表面上各方都得到保留实际上每个应用都要理解哪些字段在什么条件下有效。另一种方案是让各公司独立建模以后需要汇总时再对接。它保留了本地速度却可能让相同身份和基础关系被反复解释。这不是简单的集中与分散之争。真正需要决定的是哪些含义足够相同值得共同维护哪些不同是业务必需哪些差异可以通过配置表达哪些差异意味着应建立独立领域资产。物理系统放在哪个机房是另一个层次的问题。我对集团公共层的基本判断是共同语义、真实消费者和维护责任应当同时成立。总部不能仅凭组织位置把一个概念升格为公共资产子公司也不能只凭本地习惯拒绝所有共同约定。双方都需要说明选择带来的业务后果和持续成本。本篇将提出一种作者建议的四层结构集团核心、领域产品包、子公司扩展和场景配置。它不是任何标准强制规定的架构也不是要求每个集团都建立四套系统。它是一种划分含义、变化和责任的方法帮助企业在共用与自治之间形成可检查的契约。二、负责人决策层总部统一越多收益和协调成本可能一起增长统一的价值来自减少重复解释如果A、B两家公司每次开发应用都重新确认供应商身份、物料映射和采购关系共同资产可能减少重复工作。一个已确认身份被多处引用一次含义调整能找到相关消费者接入新应用时不必从头解释这是公共化最直接的价值来源。但公共化也把局部变化变成共同事项。原来B公司改变一个字段只需协调本地应用现在可能需要评估A公司的影响安排兼容、通知和迁移。共享建设费用下降并不意味着全生命周期成本必然下降。集团需要同时观察减少了多少重复以及增加了多少协调。所以我不会把“统一率”作为首要目标。一个对象被十个应用引用却每次修改都需要十方反复争论未必比几个边界清楚的领域资产更经济。反过来只有两家公司使用的共同身份如果长期稳定且避免大量映射也可能值得维护。公共资产需要有人愿意消费也需要有人能够供给真实消费者不是一个未来可能接入的公司名单。它应当指向明确任务和使用岗位采购风险应用需要供应主体身份调拨分析需要批次与预留关系财务分析需要能追溯到其口径的汇总。每个消费者应能说明接受共同定义以后改变什么工作。供给责任同样具体。谁确认资产含义谁处理争议谁维护源映射谁决定不兼容变更谁支持新消费者如果公共团队只能建设一次后续所有工作都退回项目组共享资产只是被集中存放并没有形成稳定供给。总部可以为尚未完全证明经济性的公共探索提供有限预算但应明确它购买的是验证证据。不能先按全集团未来规模摊薄固定成本再要求各公司必须接入以证明原来的账是对的。消费者应当帮助定义资产而不是被当成补足分母的数量。集团管理形态改变公共层的合理范围对于业务相近且管理协同较强的事业部型集团共同流程和领域语言可能较多领域包可以覆盖较完整的业务链。对于以资本和经营监督为主的控股型集团公共层可能主要是组织身份、投资关系和少量经营报告契约。多业态集团则需要更谨慎地处理跨域关系。这里描述的是可考虑的设计方向不是根据组织名称自动决定架构。实际企业可能同时存在不同管理方式同一家子公司也可能在采购上协同、在交付上自治。应以真实决策权和消费者为依据而不是把集团类型当成固定答案。负责人最终需要批准的不是“统一一切”或“全面自治”而是某些有边界的公共承诺哪些对象可以共用哪些关系可跨域查询哪些变更需要共同确认以及哪些差异由本地负责。这样的决定才能进入预算与责任安排。三、四层结构共同的部分向上放不同的部分必须有位置集团核心保持少而明确集团核心适合放置确有跨域消费者的共同身份和基础关系例如组织主体、法人身份及经确认的主体关联。它还可以提供公共资产的命名、引用和责任约定。核心的价值在于稳定连接不在于覆盖最多业务字段。某个供应主体可以同时服务制造与服务板块因此其共同身份有公共价值但在制造采购中的资格与在服务项目中的资格应分别描述。集团核心可以帮助确认“讨论的是谁”不必替所有领域回答“在这个任务中能做什么”。领域产品包承载共享业务含义领域产品包面对相近的一组问题和消费者。甲集团的制造采购包可以包含采购需求、供货资格、批次候选及相应契约连接既有规则与数据服务。它比集团核心更了解业务也应承担更明确的领域维护责任。这里的包不是简单压缩文件。它需要说明范围、对象及关系、依赖版本、数据契约、规则接口、边界样例、扩展点和支持责任。某些能力由外部系统承担也应在包中说明依赖而不是把全部实现强行搬进同一组件。子公司扩展承载有理由的本地差异B公司特殊生产地点的放行要求可以作为本地扩展C的服务合同保障则可能需要独立领域包不宜仅作为制造采购的一条例外。扩展的依据是共同核心含义仍然成立只是在限定范围内增加事实、关系或约束。扩展不应悄悄改变公共字段的含义。若公共“在手数量”指现场实际持有本地不能把扣除预留后的结果仍写入同名字段。它可以增加“本地可释放数量”明确计算前提并引用共同的在手事实。这样消费者能够理解差异公共资产也不会被本地行为污染。场景配置处理已允许变化的选择某次供应异常选择的分析时间窗口、已授权策略选项或界面显示范围可以进入场景配置。配置应使用模型和规则已经允许的自由度。如果一个修改改变了对象身份或资格含义就不应仅因为放进配置表而绕过语义评审。层次甲集团适合承载的内容主要消费者典型变化与责任集团核心组织、供应主体身份及共同引用约定多领域及集团级分析身份关系变化由共同Owner确认制造采购领域包需求、供货资格、批次候选与输入输出契约A、B采购和计划应用领域含义变化由领域Owner负责子公司扩展B特定地点的附加确认关系B本地应用及受影响协同场景本地范围变化由本地Owner提出并遵守契约场景配置一次分析的时间范围、允许的策略选项某个应用或事件在授权范围内调整由场景岗位负责公开材料提供了一个范围有限的参照。Airbus于2025年11月发布的Skywise Store应用目录将目录中的方案与Skywise Ontology联系起来并将其描述为标准化的航空公司数字孪生。这说明其公开产品体系同时呈现共同领域表示和多个应用但不能据此推导集团内部的继承、计费或净收益。Airbus官方目录第2页从这个有限事实出发我提出的设计建议是让多个应用围绕明确领域资产工作而不是把所有业务共同塞入集团核心。是否适合甲集团仍要通过实际消费者和接入成本验证。四、资产能否进入公共层先经过四项检验共同含义同名不是充分条件一个资产被多个公司称为“客户”可能分别指签约法人、最终使用者、付款主体或渠道伙伴。公共化之前应拿同一个具体实例检查不同消费者是否指向相同身份和关系。若含义不同可以共同引用主体身份却不应直接合并业务角色。测试共同含义时应比较正常样例和边界样例。两家公司都在普通订单中使用同一概念并不代表在委托、代采或跨法人履约中仍然一致。越是准备支撑动作的公共资产越需要把这些边界显式讨论。共同含义也可以很薄。例如集团只需要知道不同板块是否面对同一供应主体用于风险提示那么主体身份和领域关系引用就可能足够。公共层不必为了未来所有问题而统一合同、价格和资格。薄而真实的共同含义通常比宽而模糊的定义更容易维护。消费者使用同一名字不等于使用同一资产A公司的调拨应用和B公司的采购风险应用可能都引用供应商但消费的关系不同。评审需要确认它们究竟共用哪些部分以及这些部分的变化是否会影响各自结果。只有把具体消费方式写出来复用收益才有可验证的起点。对候选消费者我会要求提供一条实际能力问题和一组输入输出样例。若对方只表示“将来可能用到”可以记录为潜在需求但不能直接支撑当前规模预算。公共资产应先服务已确认用途同时保留合理扩展空间。变化一起创建不代表适合一起修改两家公司最初使用完全相同的字段后续变化频率和方向却可能不同。若某部分经常因本地工艺改变另一部分长期稳定把两者绑在一个版本里会增加不必要的协调。应把稳定共同结构与变化更快的差异分开。变化频率本身也不能单独决定分层。一个经常更新但所有消费者必须一致的集团主体映射仍可能需要公共维护一个很少改变但仅适用一家公司特殊用途的定义也未必值得提升到集团。关键是变化是否需要共同承认以及谁承担影响。治理责任公共化必须有人接受完整后果资产进入公共层意味着有人承担消费者支持、兼容、争议和退出责任。技术委员会可以做架构裁决但业务含义仍需要领域负责人接受。把争议上交总部不等于已经有人解决决策记录必须指向具体责任。公共准入还应包含拒绝条件。没有真实消费者、含义冲突无法划清、维护资源未落实、共享成本明显高于独立方案都可以成为暂不准入的理由。拒绝应说明如何改进而不是要求本地团队一律服从一个抽象原则。这四项检验不宜变成一个平均评分。消费者很多却没有共同含义不能靠规模得分补足语义非常漂亮却无人使用也不能靠标准化程度获批。评审可以允许探索性资产但要明确它尚未承诺稳定服务预算也按验证范围安排。五、架构落地层身份、命名空间和法人范围怎样连接集团公共层首先需要避免把“同一个人或机构”和“它在某种业务中的角色”混为一谈。某个主体可以在一个板块是供应商在另一个板块是客户也可以由不同法人分别签约。共同身份用于连接这些角色角色关系则保留领域和法人范围。甲集团可以为已确认主体维护共同引用标识同时保存源系统编码及其映射依据。共同标识不必替换所有源系统主键但必须能够说明映射对象和适用范围。源编码改变时公共身份是否改变应由身份规则决定不能只跟着字符串变化。未确认映射需要有位置。两个记录名称相似可以记录为待核实关系不能先合并再期待业务发现错误。错误合并会把不同主体的资格、履约和风险混在一起错误拆分则会让同一主体的关联无法汇总。两种后果不同检查方法也应分别设计。命名空间是避免定义碰撞的一种工程安排。本文建议集团核心、领域包和本地扩展使用可以区分归属的命名并记录每个名称的Owner和版本引用。它不只是给字段加前缀而是让消费者知道某个定义由谁维护、在哪里适用。例如制造领域的“供货资格”与服务领域的“服务资格”可以各自命名同时共同引用供应主体。B公司的“特殊工艺放行”属于本地扩展应明确它对哪些地点和物料生效。应用查询时必须知道自己使用哪个概念不能依靠展示标签“资格”猜测。法人范围尤其需要进入关系而不只是放在用户界面。一个集团主体为子公司A提供资质不一定适用于子公司B的交易A有权查看关系也不一定有权替B修改。身份相同不带来授权相同公共模型不应把组织隶属误当成无限代理关系。主体关系还会随时间改变。并购、拆分或职责调整以后当前组织结构不能直接覆盖历史关系。公共层应保存解释历史所必需的生效范围和来源使过去某次判断能在当时背景下被理解。具体时态实现可以依赖已有主数据和记录系统不必全部由本体重新保存。对于数据共享有限的板块可以先交换受控身份映射和经授权的关系摘要而不集中全部交易细节。公共层能知道“存在某种依赖”与能读取全部合同内容是不同权限。模型和查询接口应把这种差异表达出来防止调用者把可见关系当成完整事实集合。身份连接完成后也不能立即对所有指标求和。共同主体使集团知道数据相关数量是否可合并仍取决于单位、粒度和口径。公共核心负责连接领域契约负责解释汇总服务负责在声明条件下计算。分工清楚才能避免一个共享标识承担过多含义。六、实物库存、可用库存与财务存货连接它们保留不同问题甲集团最初想建立一个巨大“库存”对象是因为多个部门都在讨论同一批物资。但仓库关注实际持有计划关注某个需求下能否使用财务关注对应的记录和价值。它们共享部分身份却不共享全部口径。实物库存可以描述某地点、某批次、某时点的数量。可用库存需要进一步限定用途、质量、预留、时间和授权等条件可能是一项派生判断。财务存货的具体确认与计量应依企业适用制度和专业判断本篇不解释会计准则在架构上只要求其口径和来源不要被业务数量替代。更稳妥的设计是让三者共同引用物料、批次、组织和时间等必要身份并保留各自定义及计算责任。集团分析需要从一个视角转到另一个视角时通过明确关系和对账说明连接而不是把三者改成同名字段。假设B公司一批物料在现场但尚未完成质量放行。仓库视角下存在数量当前制造调拨视角下不能直接使用。若财务记录中也有对应条目不能由“业务不可用”直接推导该条目不存在或应如何计量。正确做法是展示各自状态及关系不替专业系统作越界判断。C服务板块进一步说明为什么名称不能强行统一。维修备件可能承担某一服务任务的保障即使当前没有具体领用单也不代表它对制造业务自由可用。C可以向集团提供经其契约计算的“可协商支援候选”同时保留本地保障逻辑。集团层面不必读取全部合同也不能假定制造采购包已经覆盖这些条件。如果跨域协商成为稳定业务可以新增一个边界清楚的跨域关系某候选资源在指定条件下可提供支援。这个关系应包含范围、证据、责任和有效时间连接两边的领域对象。它的存在不要求两边改用同一个库存模型。这样的架构可能在图上看起来比一个“统一库存”复杂却减少了隐含解释。复杂性没有因为合并字段而消失只是被转移到应用代码和人工沟通。显式保留差异让企业能够决定哪些转换值得维护哪些汇总不应提供。相反也不要为了尊重差异而拒绝所有共性。A、B确实相同的实物批次身份、单位及基础关系可以共同维护。如果每个应用连这些都重新定义跨公司分析仍会支付不必要的映射成本。分层的目标是把共同与不同放在合适位置而不是偏向任何一边。七、引用、扩展和分叉怎样让共同资产继续连在一起复用应当留下明确依赖复制一份集团采购模型到本地再随意修改是最快形成首版的方法之一也可能是最快失去共同维护的方法。集团之后改了身份规则本地副本未必知道本地增加了关系其他消费者也无法判断是否兼容。文件看起来同源实际已经没有可追踪依赖。我建议把“继承”首先理解为引用明确版本的公共资产并组合经过允许的本地差异。引用什么版本、依赖哪些概念、采用哪些扩展点都应可以查询。具体工具可能提供导入、包管理或接口引用实现方式不同责任要求相同。OWL 2入门文档讨论了本体导入等构件但标准语言的导入并不等同于企业产品的版本服务、商业兼容承诺或本地覆盖政策。本文提出的资产分层和迁移机制属于工程治理建议不能由标准支持导入直接推导它们已被解决。OWL 2入门第二版扩展必须说明自己增加了什么一个合格扩展应声明适用主体、增加的对象或关系、依赖版本、对公共行为的影响以及责任人。B公司的附加放行关系可以增加候选成立所需的本地证据但不能悄悄让共同定义中的“已确认资格”在B代表未经确认的声明。扩展可以改变最终决策结果这并不等于破坏公共语义。相同基础事实在不同业务约束下得到不同候选是合理情况。关键在于公共事实的含义保持清楚差异逻辑公开引用且在授权范围内运行。规则之间的具体冲突将在第06篇讨论本篇先保留责任和空间边界。扩展点也不能无限宽。若规定本地可以重定义任何字段公共契约就失去保证若完全禁止增加关系本地只能在系统外维护差异。应根据实际使用确定允许增加、允许配置和必须共同评审的范围并通过边界样例验证。分叉是可以选择的代价不应成为隐蔽事实当本地需求持续偏离公共含义继续扩展可能比独立维护更复杂。此时可以允许分叉但要明确新Owner、支持范围、与原资产的映射以及未来升级责任。分叉不是失败标签它是决定不再共同承担某部分变化。真正危险的是事实分叉却仍声称共享。同一个版本名在不同公司代表不同定义消费者无法判断结果为何不同集团还按共享覆盖率报告进展。应把这种情况显式登记决定恢复一致、建立正式扩展还是承认独立资产。依赖方向需要克制集团核心不宜依赖某个子公司的私有定义否则本地修改可能迫使核心调整。领域包可以引用核心本地扩展引用领域包场景配置在这些契约允许范围内运行。跨域依赖则应通过明确的公共关系或接口避免两个包互相深入引用内部结构。这是一项设计约束建议不是所有实现都必须形成严格层级。确有循环依赖时应检查是否混淆了领域边界或是否需要抽出更小的共同契约。不能只为了图形漂亮而拆分也不能放任循环使任何变更都牵动全集团。版本策略需要与实际使用相配。首轮小范围人工检查可以承担一些兼容验证消费者增加以后就需要更系统的影响分析。第09篇会讨论发布流程本篇要求先确定谁有权改变什么以及变化后由谁承担迁移。八、逻辑共同与物理集中应当分开决策集团形成共同语义并不意味着所有数据必须搬到同一平台。A、B可以使用相同采购契约事实分别来自各自业务系统C可以共享主体身份却在本地完成服务保障判断。公共模型定义交换的含义部署方式决定数据和计算如何运行。反过来所有数据集中到一个仓库也不意味着已经统一含义。同名字段可能来自不同口径身份映射可能仍然不可靠权限还可能只停留在表级。物理集中有助于某些集成工作却不能代替语义确认。部署评审应考虑时效、网络、故障隔离、数据访问要求和成本。若跨域只需要一个受控候选状态就可能让本地服务计算后返回结果若需要对大量关系进行交互查询可能需要适当索引或缓存。哪种方式合适应以目标任务验证不从分层名称直接推导。权限也应分别落实在数据、查询和动作上。共同身份服务可能可被多个领域读取但某个领域的价格和合同细节仍需受控集团可以展示一个供应风险提示却未必允许所有用户追溯到敏感明细。模型应该支持这些边界不能因为公共对象存在就默认关联内容全部可见。分布式方案同样有成本。网络不可用时怎样返回版本不一致时怎样识别本地服务升级后谁检查集团消费者结果是否带有足够来源和时间都需要工程工作。不能把“不集中数据”当成天然低成本也不能因为集成复杂就直接取消合理的数据边界。缓存与派生数据尤其需要解释。某次查询可以接受昨日风险摘要另一次候选调拨需要当前状态两者应使用不同的时效契约。共同模型可以说明它们关联同一主体但不应把摘要当实时事实。缓存失效和重新确认的责任应在运行方案里落实。当子公司退出某个公共服务集团还需要知道哪些消费者受影响、历史证据如何保留、替代查询怎样提供。退出不是只删除一个接口。若公共模型强依赖无法替换的本地实现形式上共享、实际单点依赖的问题会在退出时暴露。因此目标架构至少应有两张可相互对应的视图。一张说明资产含义、责任与依赖另一张说明数据、计算和控制部署在哪里。负责人据此可以分别判断共享范围和运行风险而不是被一张中心平台图迫使接受所有集中安排。九、甲集团完整推演两家制造公司共用采购包服务板块保留自己的边界以下全过程为教学设定只推演机制不报告真实实施效果。甲集团第一轮先确认公共组织和供应主体身份保留A、B、C原系统编码作为映射。主数据Owner维护共同身份领域团队确认各自业务角色不因主体相同就合并资格和交易条件。制造采购团队随后选定供应中断候选分析定义需求、供货资格、库存批次、预留和用途确认的关系。A、B共同评审正常与边界样例确定哪些输入输出含义相同。原系统继续提供库存事实和执行动作领域包只声明契约、依赖与必要连接。B公司提出特殊生产地点还需要附加确认。团队先检查这是否改变公共“放行”的含义最终将其定义为本地用途条件独立连接到需求与批次。公共批次状态保持不变B的候选判断增加一项前提。A消费共同采购包时不必理解B所有内部工艺但跨公司使用B批次时必须得到相应受控结果。C服务板块评审后确认维修保障不适合被塞进制造预留关系。它只引用共同主体身份和经确认的物料映射保留服务合同、任务和保障资源的领域模型。集团不要求C接入制造候选计算只要求在确有协商需求时按约定提供可支援候选及其条件。图的中文含义是集团核心提供共同组织和主体身份制造采购与服务保障分别引用。A、B在制造采购包上使用有边界的扩展C按服务领域运行。确有跨域协商时由C提供带条件的支援候选接口连接制造分析各公司原系统继续承担权威事实和动作。共同身份没有使两个领域的库存规则变成同义。在第二次接入时团队记录B复用了哪些交付物共同身份、需求结构、部分边界样例和规则接口含义。同时记录仍需完成的工作源映射、特殊用途条件、权限、业务培训和本地对账。只有把两边都记下来才能判断复用是否降低了可比任务的新增成本。随后发生一个教学变更制造采购包准备把资格关系从主体级细化到生产地点级。资产Owner先识别A、B的消费者检查是否能保留旧接口含义以及哪些查询需要新增地点。C服务包没有依赖制造资格因此不被迫同步修改但共同主体身份保持连接。如果B已经通过本地扩展表达地点关系应评估该能力能否晋升为领域公共内容。不能直接把B实现复制成集团标准A需要确认含义是否适用公共团队需要接手维护B的消费者还要迁移引用。晋升改变的是责任与承诺不只是文件位置。这个变更也提供了验证经济性的机会。若共同包使两家公司只确认一次基础含义、各自完成少量映射可能支持共享价值若所有消费者都要近乎重建说明原来边界或兼容承诺需要调整。结论应由工时、缺陷和使用结果支持不由是否按时完成集团统一指标决定。最后集团决定暂不把C的合同保障纳入采购包。这个决定保留在架构记录中说明未纳入的理由及未来重审条件只有出现稳定跨域决策且连接价值超过维护成本才进一步建设。没有纳入的范围并非遗漏而是已经作出的投资取舍。十、公共化是否省钱要比较两条完整路径公共化评审至少应比较多处独立维护与共享资产两条可行路径。独立路径包含重复确认、开发、变更和对接成本共享路径包含公共建设、协调、适配、兼容、支持和迁移成本。若只拿公共包开发费用与多份代码费用相比结果会遗漏最重要的组织工作。成本或证据多处独立建设需要观察什么共享资产需要观察什么甲集团本轮取证方式初始定义各应用分别确认同一含义的工作公共确认与边界裁决的工作记录参与岗位及可复用产物接入适配每处映射、接口与培训公共接入之外仍需的本地工作比较A首场景与B可比范围一次变更多份定义分别修改和对账影响分析、兼容及消费者迁移采用同一资格变化演练持续支持各团队独立维护与问题排查公共团队和本地团队的共同投入合并记录避免只报中心工时退出本地替换及跨应用重连资产导出、消费者迁移及历史保留为无消费者资产做退役演练使用结果是否稳定完成目标任务是否被真实消费者采用观察使用、复核和执行证据公共固定投入可以由集团承担但不能从集团总成本中消失。若首个应用承担全部公共投入会显得自身不经济若公共投入不计入任何项目又会让所有应用都显得异常划算。可以分别呈现公共固定投入、每个消费者新增投入和合并后的完整成本。新增一个消费者需要多少工作是复用经济性的关键证据。这里的新增工作包括接口、映射、权限、例外、培训、数据修复和公共团队支持。一个包被复制成功只说明技术分发完成消费者能够在同样业务质量下使用才说明完成接入。比较还需要保持任务范围可比。A首场景包含身份清理B场景只接入少量已确认对象不能直接把工时差全部归为复用。应拆出共同基础工作和场景特有工作再说明哪些减少与共享资产有关。若无法完全比较就保留限制不强行给出单一节省比例。共享价值也可能体现在变化时。一次资格定义调整若能找到全部消费者减少遗漏与重复解释属于维护改善。应记录发现依赖、确认差异、测试、迁移和故障处理的整体工作不能只统计修改模型文件用了多久。公共化还会改变等待时间。跨公司共同确认可能拖慢某些本地变化因此需要授权范围和例外路径。等待带来的经营影响应结合具体场景评估不必全部强行折算但不能因为难量化就不记录。稳定共同含义与快速本地变化分开正是降低这种成本的一种设计假设。GAO成本估算指南提供了工作分解、假设、风险分析及实际更新的方法入口。本文借用这种估算纪律强调持续修正公共化成本而不是采用任何统一财务参数。GAO成本估算指南集团收益还需要合并。A减少分析工作但B增加大量复核不能只报告A节省公共团队替各应用维护一份定义成本只是转移到中心时也不能宣称全部消失。实际净改善应包括各方新增工作现金节省、能力释放和风险改善分别记录。因此资产准入时可以先提出经济性假设但应把验证放在第二消费者和一次真实变化中。若新增接入仍近乎重建或协调成本不断上升就缩小公共范围、调整扩展点必要时把部分资产降回领域或本地。公共化是可复核的选择不是只能扩大的路线。十一、晋升、降级与退役公共边界应当可以调整本地能力晋升以前先接过维护责任B公司开发的地点资格关系如果被A确认也需要可以成为领域公共候选。评审应检查两边含义是否相同、适用范围是否清楚、是否存在可复用样例以及公共团队是否愿意持续支持。不能因为本地实现成熟就跳过共同定义和消费者验证。晋升时需要保留原消费者的迁移路径。旧名称、旧映射和历史结果可能仍然被使用公共版本应说明怎样连接、何时停止旧引用。若把代码搬进公共目录就宣布完成维护责任并未真正转移用户也可能同时依赖两套来源。公共资产也可以降级某个资产最初有多个消费者后来业务变化只剩一家公司使用公共维护可能不再划算。它可以降为领域或本地资产由实际使用方接手集团仍保存必要身份或引用关系。降级不是承认过去错误而是根据当前使用和成本调整供给。另一种降级来自语义分化。两家公司长期以不同方式解释一个公共概念协调无法带来足够收益继续维持名义一致只会掩盖分歧。可以拆成各自定义再保留明确映射或对照说明。变化后的模型更诚实也更容易解释业务结果。退役需要证明没有遗留消费者没有新增请求不等于没有依赖。某个年度分析、历史查询或低频应急流程可能仍引用旧资产。退役前应检查实际使用、登记消费者和业务确认给出替代方式或明确失去的能力。历史结果所需的模型与证据也应按实际要求保留。退役后的预算收益不能预先全额确认。只有重复服务、维护合同或实际工作确实停止才形成相应减少若旧平台因其他能力继续保留能节省的范围可能较小。架构台账需要与成本台账相连避免“已退役”只是图上移除了一个框。资产争议可以采用分层裁决领域含义由有权业务Owner确认跨域公共接口由相关领域共同确认资金与重大范围由集团负责人决定。技术团队负责展示依赖和后果不应独立裁定本地经营政策。组织责任会在第08篇展开这里先确保公共化决定有人承担。每项准入、晋升、降级或退役都应留下当时证据及重审条件。这样后来的团队可以理解为什么资产位于这一层而不是把历史选择误认成永远正确的原则。集团架构的稳定性来自可解释的变化不是边界永远不动。十二、两种极端都昂贵超大公共对象与每个应用一套模型第一个反例是把所有子公司的物料字段并成一个“集团物料”。制造原料、维修备件、项目耗材拥有大量可空字段再用类型标记决定哪些有效。刚开始似乎不必争论边界后续每增加一个消费者就会增加新的条件和例外。这种模型的维护困难不只是字段多而是含义与责任变得模糊。某个字段修改会不会影响其他类型谁有权决定公共约束应用是否可以忽略不适用属性都需要反复确认。表面上统一了对象实际把差异判断分散到每个消费者。若所有消费者确实共享稳定含义一个较宽对象也可能合理。反例针对的是仅为统一名称而合并不是宣布大对象必然错误。检验方法仍然是具体问题、边界样例、变化影响与责任而不是规定所有对象都必须小到相同程度。第二个反例是每个应用复制采购对象。首轮开发快速本地团队也容易调整但相同供应主体的映射逐渐不同资格定义变化时需要逐个排查集团分析无法知道哪个版本才适用。若这些共性确实稳定长期重复维护可能超过建立公共资产的成本。它也有适用边界。一个短期、独立、没有共享消费者的分析试验可以先保留本地模型只要明确期限与用途。问题在于试验长期运行以后仍以“临时”名义逃避责任和维护也不重新评价是否应公共化。负责人可以用一次具体评审避免这两个极端。选择一个候选资产请各消费者提供相同与不同的样例列出一次修改会影响哪些任务再比较独立维护与共享维护的完整工作。讨论到最后应能够指出共同核心、领域差异、本地扩展和场景配置分别是什么。我建议评审留下三份互相关联的记录目标分层图、资产准入表和复用经济性假设。图说明在哪里准入表说明为什么及谁负责经济性假设说明怎样验证值得共同投入。三者如果不能相互对应架构仍然可能只是一张理想图。在甲集团这次决定可以很克制共同组织与供应主体身份进入核心A、B验证制造采购包B保留有契约的附加条件C维护服务领域只在明确需求下提供受控连接第二消费者接入与一次变化完成后再核验公共化成本。这样的决定并没有预先完成整个集团本体却已经解决了一个关键问题下一步建模发生在哪里谁可以改变什么哪些成果应共同维护哪些差异可以被尊重。第05篇将从这条已经划定的领域边界出发把一个经营问题变成最小可用、可验收的本体。 
长河君 · 2026/11/6 5:16:58 · 阅读 1.2k 总部统一到哪里：集团核心、领域产品与子公司扩展如何分层
《AI时代的集团Ontology从架构决策到产品运营》第04篇给负责人先读第一至四节、第十至十二节判断哪些资产值得共同投入。给架构师第五至九节展开身份、契约、扩展、部署及完整接入推演。甲集团、A与B制造公司、C服务板块及全部经营情节均为虚构教学设定不对应真实客户。一、一个“集团可用库存”为什么让三家公司都不满意甲集团完成了首轮准备检查决定继续验证A、B两家制造公司的供应中断处置。集团技术团队准备建立统一库存对象并请C服务板块一起提供字段。大家都希望减少重复建设讨论却很快遇到阻力。A公司希望“可用库存”扣除已预留数量并考虑用途批准。B公司提出某些预留经过授权后可以调整不能一律排除。C公司认为维修备件承担服务合同保障同样的在手数量可能根本不能进入制造调拨。财务团队又提醒账面存货价值与现场可调数量不是同一个问题。一种方案是把所有字段都放进集团对象再增加公司、业务类型和例外标识。表面上各方都得到保留实际上每个应用都要理解哪些字段在什么条件下有效。另一种方案是让各公司独立建模以后需要汇总时再对接。它保留了本地速度却可能让相同身份和基础关系被反复解释。这不是简单的集中与分散之争。真正需要决定的是哪些含义足够相同值得共同维护哪些不同是业务必需哪些差异可以通过配置表达哪些差异意味着应建立独立领域资产。物理系统放在哪个机房是另一个层次的问题。我对集团公共层的基本判断是共同语义、真实消费者和维护责任应当同时成立。总部不能仅凭组织位置把一个概念升格为公共资产子公司也不能只凭本地习惯拒绝所有共同约定。双方都需要说明选择带来的业务后果和持续成本。本篇将提出一种作者建议的四层结构集团核心、领域产品包、子公司扩展和场景配置。它不是任何标准强制规定的架构也不是要求每个集团都建立四套系统。它是一种划分含义、变化和责任的方法帮助企业在共用与自治之间形成可检查的契约。二、负责人决策层总部统一越多收益和协调成本可能一起增长统一的价值来自减少重复解释如果A、B两家公司每次开发应用都重新确认供应商身份、物料映射和采购关系共同资产可能减少重复工作。一个已确认身份被多处引用一次含义调整能找到相关消费者接入新应用时不必从头解释这是公共化最直接的价值来源。但公共化也把局部变化变成共同事项。原来B公司改变一个字段只需协调本地应用现在可能需要评估A公司的影响安排兼容、通知和迁移。共享建设费用下降并不意味着全生命周期成本必然下降。集团需要同时观察减少了多少重复以及增加了多少协调。所以我不会把“统一率”作为首要目标。一个对象被十个应用引用却每次修改都需要十方反复争论未必比几个边界清楚的领域资产更经济。反过来只有两家公司使用的共同身份如果长期稳定且避免大量映射也可能值得维护。公共资产需要有人愿意消费也需要有人能够供给真实消费者不是一个未来可能接入的公司名单。它应当指向明确任务和使用岗位采购风险应用需要供应主体身份调拨分析需要批次与预留关系财务分析需要能追溯到其口径的汇总。每个消费者应能说明接受共同定义以后改变什么工作。供给责任同样具体。谁确认资产含义谁处理争议谁维护源映射谁决定不兼容变更谁支持新消费者如果公共团队只能建设一次后续所有工作都退回项目组共享资产只是被集中存放并没有形成稳定供给。总部可以为尚未完全证明经济性的公共探索提供有限预算但应明确它购买的是验证证据。不能先按全集团未来规模摊薄固定成本再要求各公司必须接入以证明原来的账是对的。消费者应当帮助定义资产而不是被当成补足分母的数量。集团管理形态改变公共层的合理范围对于业务相近且管理协同较强的事业部型集团共同流程和领域语言可能较多领域包可以覆盖较完整的业务链。对于以资本和经营监督为主的控股型集团公共层可能主要是组织身份、投资关系和少量经营报告契约。多业态集团则需要更谨慎地处理跨域关系。这里描述的是可考虑的设计方向不是根据组织名称自动决定架构。实际企业可能同时存在不同管理方式同一家子公司也可能在采购上协同、在交付上自治。应以真实决策权和消费者为依据而不是把集团类型当成固定答案。负责人最终需要批准的不是“统一一切”或“全面自治”而是某些有边界的公共承诺哪些对象可以共用哪些关系可跨域查询哪些变更需要共同确认以及哪些差异由本地负责。这样的决定才能进入预算与责任安排。三、四层结构共同的部分向上放不同的部分必须有位置集团核心保持少而明确集团核心适合放置确有跨域消费者的共同身份和基础关系例如组织主体、法人身份及经确认的主体关联。它还可以提供公共资产的命名、引用和责任约定。核心的价值在于稳定连接不在于覆盖最多业务字段。某个供应主体可以同时服务制造与服务板块因此其共同身份有公共价值但在制造采购中的资格与在服务项目中的资格应分别描述。集团核心可以帮助确认“讨论的是谁”不必替所有领域回答“在这个任务中能做什么”。领域产品包承载共享业务含义领域产品包面对相近的一组问题和消费者。甲集团的制造采购包可以包含采购需求、供货资格、批次候选及相应契约连接既有规则与数据服务。它比集团核心更了解业务也应承担更明确的领域维护责任。这里的包不是简单压缩文件。它需要说明范围、对象及关系、依赖版本、数据契约、规则接口、边界样例、扩展点和支持责任。某些能力由外部系统承担也应在包中说明依赖而不是把全部实现强行搬进同一组件。子公司扩展承载有理由的本地差异B公司特殊生产地点的放行要求可以作为本地扩展C的服务合同保障则可能需要独立领域包不宜仅作为制造采购的一条例外。扩展的依据是共同核心含义仍然成立只是在限定范围内增加事实、关系或约束。扩展不应悄悄改变公共字段的含义。若公共“在手数量”指现场实际持有本地不能把扣除预留后的结果仍写入同名字段。它可以增加“本地可释放数量”明确计算前提并引用共同的在手事实。这样消费者能够理解差异公共资产也不会被本地行为污染。场景配置处理已允许变化的选择某次供应异常选择的分析时间窗口、已授权策略选项或界面显示范围可以进入场景配置。配置应使用模型和规则已经允许的自由度。如果一个修改改变了对象身份或资格含义就不应仅因为放进配置表而绕过语义评审。层次甲集团适合承载的内容主要消费者典型变化与责任集团核心组织、供应主体身份及共同引用约定多领域及集团级分析身份关系变化由共同Owner确认制造采购领域包需求、供货资格、批次候选与输入输出契约A、B采购和计划应用领域含义变化由领域Owner负责子公司扩展B特定地点的附加确认关系B本地应用及受影响协同场景本地范围变化由本地Owner提出并遵守契约场景配置一次分析的时间范围、允许的策略选项某个应用或事件在授权范围内调整由场景岗位负责公开材料提供了一个范围有限的参照。Airbus于2025年11月发布的Skywise Store应用目录将目录中的方案与Skywise Ontology联系起来并将其描述为标准化的航空公司数字孪生。这说明其公开产品体系同时呈现共同领域表示和多个应用但不能据此推导集团内部的继承、计费或净收益。Airbus官方目录第2页从这个有限事实出发我提出的设计建议是让多个应用围绕明确领域资产工作而不是把所有业务共同塞入集团核心。是否适合甲集团仍要通过实际消费者和接入成本验证。四、资产能否进入公共层先经过四项检验共同含义同名不是充分条件一个资产被多个公司称为“客户”可能分别指签约法人、最终使用者、付款主体或渠道伙伴。公共化之前应拿同一个具体实例检查不同消费者是否指向相同身份和关系。若含义不同可以共同引用主体身份却不应直接合并业务角色。测试共同含义时应比较正常样例和边界样例。两家公司都在普通订单中使用同一概念并不代表在委托、代采或跨法人履约中仍然一致。越是准备支撑动作的公共资产越需要把这些边界显式讨论。共同含义也可以很薄。例如集团只需要知道不同板块是否面对同一供应主体用于风险提示那么主体身份和领域关系引用就可能足够。公共层不必为了未来所有问题而统一合同、价格和资格。薄而真实的共同含义通常比宽而模糊的定义更容易维护。消费者使用同一名字不等于使用同一资产A公司的调拨应用和B公司的采购风险应用可能都引用供应商但消费的关系不同。评审需要确认它们究竟共用哪些部分以及这些部分的变化是否会影响各自结果。只有把具体消费方式写出来复用收益才有可验证的起点。对候选消费者我会要求提供一条实际能力问题和一组输入输出样例。若对方只表示“将来可能用到”可以记录为潜在需求但不能直接支撑当前规模预算。公共资产应先服务已确认用途同时保留合理扩展空间。变化一起创建不代表适合一起修改两家公司最初使用完全相同的字段后续变化频率和方向却可能不同。若某部分经常因本地工艺改变另一部分长期稳定把两者绑在一个版本里会增加不必要的协调。应把稳定共同结构与变化更快的差异分开。变化频率本身也不能单独决定分层。一个经常更新但所有消费者必须一致的集团主体映射仍可能需要公共维护一个很少改变但仅适用一家公司特殊用途的定义也未必值得提升到集团。关键是变化是否需要共同承认以及谁承担影响。治理责任公共化必须有人接受完整后果资产进入公共层意味着有人承担消费者支持、兼容、争议和退出责任。技术委员会可以做架构裁决但业务含义仍需要领域负责人接受。把争议上交总部不等于已经有人解决决策记录必须指向具体责任。公共准入还应包含拒绝条件。没有真实消费者、含义冲突无法划清、维护资源未落实、共享成本明显高于独立方案都可以成为暂不准入的理由。拒绝应说明如何改进而不是要求本地团队一律服从一个抽象原则。这四项检验不宜变成一个平均评分。消费者很多却没有共同含义不能靠规模得分补足语义非常漂亮却无人使用也不能靠标准化程度获批。评审可以允许探索性资产但要明确它尚未承诺稳定服务预算也按验证范围安排。五、架构落地层身份、命名空间和法人范围怎样连接集团公共层首先需要避免把“同一个人或机构”和“它在某种业务中的角色”混为一谈。某个主体可以在一个板块是供应商在另一个板块是客户也可以由不同法人分别签约。共同身份用于连接这些角色角色关系则保留领域和法人范围。甲集团可以为已确认主体维护共同引用标识同时保存源系统编码及其映射依据。共同标识不必替换所有源系统主键但必须能够说明映射对象和适用范围。源编码改变时公共身份是否改变应由身份规则决定不能只跟着字符串变化。未确认映射需要有位置。两个记录名称相似可以记录为待核实关系不能先合并再期待业务发现错误。错误合并会把不同主体的资格、履约和风险混在一起错误拆分则会让同一主体的关联无法汇总。两种后果不同检查方法也应分别设计。命名空间是避免定义碰撞的一种工程安排。本文建议集团核心、领域包和本地扩展使用可以区分归属的命名并记录每个名称的Owner和版本引用。它不只是给字段加前缀而是让消费者知道某个定义由谁维护、在哪里适用。例如制造领域的“供货资格”与服务领域的“服务资格”可以各自命名同时共同引用供应主体。B公司的“特殊工艺放行”属于本地扩展应明确它对哪些地点和物料生效。应用查询时必须知道自己使用哪个概念不能依靠展示标签“资格”猜测。法人范围尤其需要进入关系而不只是放在用户界面。一个集团主体为子公司A提供资质不一定适用于子公司B的交易A有权查看关系也不一定有权替B修改。身份相同不带来授权相同公共模型不应把组织隶属误当成无限代理关系。主体关系还会随时间改变。并购、拆分或职责调整以后当前组织结构不能直接覆盖历史关系。公共层应保存解释历史所必需的生效范围和来源使过去某次判断能在当时背景下被理解。具体时态实现可以依赖已有主数据和记录系统不必全部由本体重新保存。对于数据共享有限的板块可以先交换受控身份映射和经授权的关系摘要而不集中全部交易细节。公共层能知道“存在某种依赖”与能读取全部合同内容是不同权限。模型和查询接口应把这种差异表达出来防止调用者把可见关系当成完整事实集合。身份连接完成后也不能立即对所有指标求和。共同主体使集团知道数据相关数量是否可合并仍取决于单位、粒度和口径。公共核心负责连接领域契约负责解释汇总服务负责在声明条件下计算。分工清楚才能避免一个共享标识承担过多含义。六、实物库存、可用库存与财务存货连接它们保留不同问题甲集团最初想建立一个巨大“库存”对象是因为多个部门都在讨论同一批物资。但仓库关注实际持有计划关注某个需求下能否使用财务关注对应的记录和价值。它们共享部分身份却不共享全部口径。实物库存可以描述某地点、某批次、某时点的数量。可用库存需要进一步限定用途、质量、预留、时间和授权等条件可能是一项派生判断。财务存货的具体确认与计量应依企业适用制度和专业判断本篇不解释会计准则在架构上只要求其口径和来源不要被业务数量替代。更稳妥的设计是让三者共同引用物料、批次、组织和时间等必要身份并保留各自定义及计算责任。集团分析需要从一个视角转到另一个视角时通过明确关系和对账说明连接而不是把三者改成同名字段。假设B公司一批物料在现场但尚未完成质量放行。仓库视角下存在数量当前制造调拨视角下不能直接使用。若财务记录中也有对应条目不能由“业务不可用”直接推导该条目不存在或应如何计量。正确做法是展示各自状态及关系不替专业系统作越界判断。C服务板块进一步说明为什么名称不能强行统一。维修备件可能承担某一服务任务的保障即使当前没有具体领用单也不代表它对制造业务自由可用。C可以向集团提供经其契约计算的“可协商支援候选”同时保留本地保障逻辑。集团层面不必读取全部合同也不能假定制造采购包已经覆盖这些条件。如果跨域协商成为稳定业务可以新增一个边界清楚的跨域关系某候选资源在指定条件下可提供支援。这个关系应包含范围、证据、责任和有效时间连接两边的领域对象。它的存在不要求两边改用同一个库存模型。这样的架构可能在图上看起来比一个“统一库存”复杂却减少了隐含解释。复杂性没有因为合并字段而消失只是被转移到应用代码和人工沟通。显式保留差异让企业能够决定哪些转换值得维护哪些汇总不应提供。相反也不要为了尊重差异而拒绝所有共性。A、B确实相同的实物批次身份、单位及基础关系可以共同维护。如果每个应用连这些都重新定义跨公司分析仍会支付不必要的映射成本。分层的目标是把共同与不同放在合适位置而不是偏向任何一边。七、引用、扩展和分叉怎样让共同资产继续连在一起复用应当留下明确依赖复制一份集团采购模型到本地再随意修改是最快形成首版的方法之一也可能是最快失去共同维护的方法。集团之后改了身份规则本地副本未必知道本地增加了关系其他消费者也无法判断是否兼容。文件看起来同源实际已经没有可追踪依赖。我建议把“继承”首先理解为引用明确版本的公共资产并组合经过允许的本地差异。引用什么版本、依赖哪些概念、采用哪些扩展点都应可以查询。具体工具可能提供导入、包管理或接口引用实现方式不同责任要求相同。OWL 2入门文档讨论了本体导入等构件但标准语言的导入并不等同于企业产品的版本服务、商业兼容承诺或本地覆盖政策。本文提出的资产分层和迁移机制属于工程治理建议不能由标准支持导入直接推导它们已被解决。OWL 2入门第二版扩展必须说明自己增加了什么一个合格扩展应声明适用主体、增加的对象或关系、依赖版本、对公共行为的影响以及责任人。B公司的附加放行关系可以增加候选成立所需的本地证据但不能悄悄让共同定义中的“已确认资格”在B代表未经确认的声明。扩展可以改变最终决策结果这并不等于破坏公共语义。相同基础事实在不同业务约束下得到不同候选是合理情况。关键在于公共事实的含义保持清楚差异逻辑公开引用且在授权范围内运行。规则之间的具体冲突将在第06篇讨论本篇先保留责任和空间边界。扩展点也不能无限宽。若规定本地可以重定义任何字段公共契约就失去保证若完全禁止增加关系本地只能在系统外维护差异。应根据实际使用确定允许增加、允许配置和必须共同评审的范围并通过边界样例验证。分叉是可以选择的代价不应成为隐蔽事实当本地需求持续偏离公共含义继续扩展可能比独立维护更复杂。此时可以允许分叉但要明确新Owner、支持范围、与原资产的映射以及未来升级责任。分叉不是失败标签它是决定不再共同承担某部分变化。真正危险的是事实分叉却仍声称共享。同一个版本名在不同公司代表不同定义消费者无法判断结果为何不同集团还按共享覆盖率报告进展。应把这种情况显式登记决定恢复一致、建立正式扩展还是承认独立资产。依赖方向需要克制集团核心不宜依赖某个子公司的私有定义否则本地修改可能迫使核心调整。领域包可以引用核心本地扩展引用领域包场景配置在这些契约允许范围内运行。跨域依赖则应通过明确的公共关系或接口避免两个包互相深入引用内部结构。这是一项设计约束建议不是所有实现都必须形成严格层级。确有循环依赖时应检查是否混淆了领域边界或是否需要抽出更小的共同契约。不能只为了图形漂亮而拆分也不能放任循环使任何变更都牵动全集团。版本策略需要与实际使用相配。首轮小范围人工检查可以承担一些兼容验证消费者增加以后就需要更系统的影响分析。第09篇会讨论发布流程本篇要求先确定谁有权改变什么以及变化后由谁承担迁移。八、逻辑共同与物理集中应当分开决策集团形成共同语义并不意味着所有数据必须搬到同一平台。A、B可以使用相同采购契约事实分别来自各自业务系统C可以共享主体身份却在本地完成服务保障判断。公共模型定义交换的含义部署方式决定数据和计算如何运行。反过来所有数据集中到一个仓库也不意味着已经统一含义。同名字段可能来自不同口径身份映射可能仍然不可靠权限还可能只停留在表级。物理集中有助于某些集成工作却不能代替语义确认。部署评审应考虑时效、网络、故障隔离、数据访问要求和成本。若跨域只需要一个受控候选状态就可能让本地服务计算后返回结果若需要对大量关系进行交互查询可能需要适当索引或缓存。哪种方式合适应以目标任务验证不从分层名称直接推导。权限也应分别落实在数据、查询和动作上。共同身份服务可能可被多个领域读取但某个领域的价格和合同细节仍需受控集团可以展示一个供应风险提示却未必允许所有用户追溯到敏感明细。模型应该支持这些边界不能因为公共对象存在就默认关联内容全部可见。分布式方案同样有成本。网络不可用时怎样返回版本不一致时怎样识别本地服务升级后谁检查集团消费者结果是否带有足够来源和时间都需要工程工作。不能把“不集中数据”当成天然低成本也不能因为集成复杂就直接取消合理的数据边界。缓存与派生数据尤其需要解释。某次查询可以接受昨日风险摘要另一次候选调拨需要当前状态两者应使用不同的时效契约。共同模型可以说明它们关联同一主体但不应把摘要当实时事实。缓存失效和重新确认的责任应在运行方案里落实。当子公司退出某个公共服务集团还需要知道哪些消费者受影响、历史证据如何保留、替代查询怎样提供。退出不是只删除一个接口。若公共模型强依赖无法替换的本地实现形式上共享、实际单点依赖的问题会在退出时暴露。因此目标架构至少应有两张可相互对应的视图。一张说明资产含义、责任与依赖另一张说明数据、计算和控制部署在哪里。负责人据此可以分别判断共享范围和运行风险而不是被一张中心平台图迫使接受所有集中安排。九、甲集团完整推演两家制造公司共用采购包服务板块保留自己的边界以下全过程为教学设定只推演机制不报告真实实施效果。甲集团第一轮先确认公共组织和供应主体身份保留A、B、C原系统编码作为映射。主数据Owner维护共同身份领域团队确认各自业务角色不因主体相同就合并资格和交易条件。制造采购团队随后选定供应中断候选分析定义需求、供货资格、库存批次、预留和用途确认的关系。A、B共同评审正常与边界样例确定哪些输入输出含义相同。原系统继续提供库存事实和执行动作领域包只声明契约、依赖与必要连接。B公司提出特殊生产地点还需要附加确认。团队先检查这是否改变公共“放行”的含义最终将其定义为本地用途条件独立连接到需求与批次。公共批次状态保持不变B的候选判断增加一项前提。A消费共同采购包时不必理解B所有内部工艺但跨公司使用B批次时必须得到相应受控结果。C服务板块评审后确认维修保障不适合被塞进制造预留关系。它只引用共同主体身份和经确认的物料映射保留服务合同、任务和保障资源的领域模型。集团不要求C接入制造候选计算只要求在确有协商需求时按约定提供可支援候选及其条件。图的中文含义是集团核心提供共同组织和主体身份制造采购与服务保障分别引用。A、B在制造采购包上使用有边界的扩展C按服务领域运行。确有跨域协商时由C提供带条件的支援候选接口连接制造分析各公司原系统继续承担权威事实和动作。共同身份没有使两个领域的库存规则变成同义。在第二次接入时团队记录B复用了哪些交付物共同身份、需求结构、部分边界样例和规则接口含义。同时记录仍需完成的工作源映射、特殊用途条件、权限、业务培训和本地对账。只有把两边都记下来才能判断复用是否降低了可比任务的新增成本。随后发生一个教学变更制造采购包准备把资格关系从主体级细化到生产地点级。资产Owner先识别A、B的消费者检查是否能保留旧接口含义以及哪些查询需要新增地点。C服务包没有依赖制造资格因此不被迫同步修改但共同主体身份保持连接。如果B已经通过本地扩展表达地点关系应评估该能力能否晋升为领域公共内容。不能直接把B实现复制成集团标准A需要确认含义是否适用公共团队需要接手维护B的消费者还要迁移引用。晋升改变的是责任与承诺不只是文件位置。这个变更也提供了验证经济性的机会。若共同包使两家公司只确认一次基础含义、各自完成少量映射可能支持共享价值若所有消费者都要近乎重建说明原来边界或兼容承诺需要调整。结论应由工时、缺陷和使用结果支持不由是否按时完成集团统一指标决定。最后集团决定暂不把C的合同保障纳入采购包。这个决定保留在架构记录中说明未纳入的理由及未来重审条件只有出现稳定跨域决策且连接价值超过维护成本才进一步建设。没有纳入的范围并非遗漏而是已经作出的投资取舍。十、公共化是否省钱要比较两条完整路径公共化评审至少应比较多处独立维护与共享资产两条可行路径。独立路径包含重复确认、开发、变更和对接成本共享路径包含公共建设、协调、适配、兼容、支持和迁移成本。若只拿公共包开发费用与多份代码费用相比结果会遗漏最重要的组织工作。成本或证据多处独立建设需要观察什么共享资产需要观察什么甲集团本轮取证方式初始定义各应用分别确认同一含义的工作公共确认与边界裁决的工作记录参与岗位及可复用产物接入适配每处映射、接口与培训公共接入之外仍需的本地工作比较A首场景与B可比范围一次变更多份定义分别修改和对账影响分析、兼容及消费者迁移采用同一资格变化演练持续支持各团队独立维护与问题排查公共团队和本地团队的共同投入合并记录避免只报中心工时退出本地替换及跨应用重连资产导出、消费者迁移及历史保留为无消费者资产做退役演练使用结果是否稳定完成目标任务是否被真实消费者采用观察使用、复核和执行证据公共固定投入可以由集团承担但不能从集团总成本中消失。若首个应用承担全部公共投入会显得自身不经济若公共投入不计入任何项目又会让所有应用都显得异常划算。可以分别呈现公共固定投入、每个消费者新增投入和合并后的完整成本。新增一个消费者需要多少工作是复用经济性的关键证据。这里的新增工作包括接口、映射、权限、例外、培训、数据修复和公共团队支持。一个包被复制成功只说明技术分发完成消费者能够在同样业务质量下使用才说明完成接入。比较还需要保持任务范围可比。A首场景包含身份清理B场景只接入少量已确认对象不能直接把工时差全部归为复用。应拆出共同基础工作和场景特有工作再说明哪些减少与共享资产有关。若无法完全比较就保留限制不强行给出单一节省比例。共享价值也可能体现在变化时。一次资格定义调整若能找到全部消费者减少遗漏与重复解释属于维护改善。应记录发现依赖、确认差异、测试、迁移和故障处理的整体工作不能只统计修改模型文件用了多久。公共化还会改变等待时间。跨公司共同确认可能拖慢某些本地变化因此需要授权范围和例外路径。等待带来的经营影响应结合具体场景评估不必全部强行折算但不能因为难量化就不记录。稳定共同含义与快速本地变化分开正是降低这种成本的一种设计假设。GAO成本估算指南提供了工作分解、假设、风险分析及实际更新的方法入口。本文借用这种估算纪律强调持续修正公共化成本而不是采用任何统一财务参数。GAO成本估算指南集团收益还需要合并。A减少分析工作但B增加大量复核不能只报告A节省公共团队替各应用维护一份定义成本只是转移到中心时也不能宣称全部消失。实际净改善应包括各方新增工作现金节省、能力释放和风险改善分别记录。因此资产准入时可以先提出经济性假设但应把验证放在第二消费者和一次真实变化中。若新增接入仍近乎重建或协调成本不断上升就缩小公共范围、调整扩展点必要时把部分资产降回领域或本地。公共化是可复核的选择不是只能扩大的路线。十一、晋升、降级与退役公共边界应当可以调整本地能力晋升以前先接过维护责任B公司开发的地点资格关系如果被A确认也需要可以成为领域公共候选。评审应检查两边含义是否相同、适用范围是否清楚、是否存在可复用样例以及公共团队是否愿意持续支持。不能因为本地实现成熟就跳过共同定义和消费者验证。晋升时需要保留原消费者的迁移路径。旧名称、旧映射和历史结果可能仍然被使用公共版本应说明怎样连接、何时停止旧引用。若把代码搬进公共目录就宣布完成维护责任并未真正转移用户也可能同时依赖两套来源。公共资产也可以降级某个资产最初有多个消费者后来业务变化只剩一家公司使用公共维护可能不再划算。它可以降为领域或本地资产由实际使用方接手集团仍保存必要身份或引用关系。降级不是承认过去错误而是根据当前使用和成本调整供给。另一种降级来自语义分化。两家公司长期以不同方式解释一个公共概念协调无法带来足够收益继续维持名义一致只会掩盖分歧。可以拆成各自定义再保留明确映射或对照说明。变化后的模型更诚实也更容易解释业务结果。退役需要证明没有遗留消费者没有新增请求不等于没有依赖。某个年度分析、历史查询或低频应急流程可能仍引用旧资产。退役前应检查实际使用、登记消费者和业务确认给出替代方式或明确失去的能力。历史结果所需的模型与证据也应按实际要求保留。退役后的预算收益不能预先全额确认。只有重复服务、维护合同或实际工作确实停止才形成相应减少若旧平台因其他能力继续保留能节省的范围可能较小。架构台账需要与成本台账相连避免“已退役”只是图上移除了一个框。资产争议可以采用分层裁决领域含义由有权业务Owner确认跨域公共接口由相关领域共同确认资金与重大范围由集团负责人决定。技术团队负责展示依赖和后果不应独立裁定本地经营政策。组织责任会在第08篇展开这里先确保公共化决定有人承担。每项准入、晋升、降级或退役都应留下当时证据及重审条件。这样后来的团队可以理解为什么资产位于这一层而不是把历史选择误认成永远正确的原则。集团架构的稳定性来自可解释的变化不是边界永远不动。十二、两种极端都昂贵超大公共对象与每个应用一套模型第一个反例是把所有子公司的物料字段并成一个“集团物料”。制造原料、维修备件、项目耗材拥有大量可空字段再用类型标记决定哪些有效。刚开始似乎不必争论边界后续每增加一个消费者就会增加新的条件和例外。这种模型的维护困难不只是字段多而是含义与责任变得模糊。某个字段修改会不会影响其他类型谁有权决定公共约束应用是否可以忽略不适用属性都需要反复确认。表面上统一了对象实际把差异判断分散到每个消费者。若所有消费者确实共享稳定含义一个较宽对象也可能合理。反例针对的是仅为统一名称而合并不是宣布大对象必然错误。检验方法仍然是具体问题、边界样例、变化影响与责任而不是规定所有对象都必须小到相同程度。第二个反例是每个应用复制采购对象。首轮开发快速本地团队也容易调整但相同供应主体的映射逐渐不同资格定义变化时需要逐个排查集团分析无法知道哪个版本才适用。若这些共性确实稳定长期重复维护可能超过建立公共资产的成本。它也有适用边界。一个短期、独立、没有共享消费者的分析试验可以先保留本地模型只要明确期限与用途。问题在于试验长期运行以后仍以“临时”名义逃避责任和维护也不重新评价是否应公共化。负责人可以用一次具体评审避免这两个极端。选择一个候选资产请各消费者提供相同与不同的样例列出一次修改会影响哪些任务再比较独立维护与共享维护的完整工作。讨论到最后应能够指出共同核心、领域差异、本地扩展和场景配置分别是什么。我建议评审留下三份互相关联的记录目标分层图、资产准入表和复用经济性假设。图说明在哪里准入表说明为什么及谁负责经济性假设说明怎样验证值得共同投入。三者如果不能相互对应架构仍然可能只是一张理想图。在甲集团这次决定可以很克制共同组织与供应主体身份进入核心A、B验证制造采购包B保留有契约的附加条件C维护服务领域只在明确需求下提供受控连接第二消费者接入与一次变化完成后再核验公共化成本。这样的决定并没有预先完成整个集团本体却已经解决了一个关键问题下一步建模发生在哪里谁可以改变什么哪些成果应共同维护哪些差异可以被尊重。第05篇将从这条已经划定的领域边界出发把一个经营问题变成最小可用、可验收的本体。