Domain Knowledge
领域知识
这里放的是信息化建设里的业务域知识：行业规则、关键对象、数据模型、业务流程和系统边界。
它不替代技术分支，也不是纯业务操作手册；它负责回答“系统到底在替哪类业务问题建模”。
4 个入口组
政务财务、司库建设、银企直联、油气行业，后续继续扩展银行、电力、电商等
业务规则优先
先抓关键对象、状态机、业务约束，再谈页面和接口
完成度分层
政务财务较厚，司库和油气已有总览，银企直联独立成专题
与技术分支配合
domain 回答"做什么"，tech 回答"怎么做"
领域页的第一用法不是从头读完，而是把眼前的系统问题归类：是财政预算、企业资金、银行通道，还是工业过程。入口选错，后面的数据模型和流程边界都会跟着歪。
如果你关心“钱从预算到支付怎么闭环”
先进入政务财务。重点不是会计名词本身，而是预算指标、项目经费、报销审批、国库支付、凭证核算和报表关账如何互相约束。
如果你关心“集团资金怎么可视、归集和支付”
先进入司库建设。重点是账户、余额、头寸、支付指令、银行流水、授信和内部往来这些对象如何连成资金控制链。
如果你关心“银行接口、报文和回单状态怎么稳住”
直接进入银企直联。它既服务司库，也会被财务支付、对账、电子回单、银行余额查询等场景反复调用，所以单独成线更清楚。
如果你关心“工业现场、仿真和调度怎么进入业务系统”
先进入油气行业。当前最成熟的深页是海底管道多相流模拟，适合从工程仿真、管道输送和过程工业系统边界切入。
定位：信息化建设的业务知识
不是教人如何做业务操作，而是理解业务规则后，抽象为数据模型、业务逻辑、状态机，支撑系统设计。
业务规则
→
数据模型
→
系统设计
与纯业务知识的区别
纯业务知识教柜员如何办业务，领域知识教架构师如何设计账户模型。受众不同，深度不同，目标不同。
纯业务 → 业务人员
→
领域知识 → 系统建设者
与技术分支的关系
领域知识是系统设计的"输入"，技术实现是"输出"。先理解业务要做什么，再决定如何用技术实现。
domain（做什么）
→
tech（怎么做）
面向单位财务信息化的业务知识体系：从预算编制到支付执行，从账务核算到报表决算。
覆盖预算层、执行层、资金层、核算层、存量层五层架构，双核算体系平行记账。
企业资金管理的业务知识：账户管理、现金池、支付结算、融资统筹、银企直联、资金风控。
国资委要求央企建设世界一流司库体系，实现资金"看得见、管得住、调得动、用得好"。
银企直联不是完整的“银行业知识分支”，而是财务、司库、支付、回单、对账都会反复依赖的银行通道专题。
它回答的是：企业系统怎样在多银行、多协议、多状态的真实世界里保持资金操作正确、可追溯。
石油天然气行业的信息化建设知识：勘探开发、管道储运、炼油化工、成品油销售。
覆盖上游、中游、下游全产业链的业务规则与数据模型。
后续将补充银行、电力、电商等领域的业务知识。
存款、贷款、支付清算、风险管理的业务规则与数据模型。
存贷汇
风控模型
清算规则
发电、输电、配电、调度、交易的业务规则与数据模型。
发输配用
调度规则
交易结算
商品、订单、库存、履约、售后的业务规则与数据模型。
SKU模型
订单状态机
库存扣减