领域模型原则¶

1. 治理¶

核心原则¶

每项资源都必须归属于某个领域。 表、视图和关系都是领域资产。不存在未经治理的游离资源。领域是问责的单位。
每个领域都必须有数据管家。 领域在指派数据管家之前可以处于待处理状态，但没有数据管家便不能提供受治理的数据。
管理员拥有数据源。 数据源属于基础设施，而非领域资源。管理员负责注册和管理与外部数据系统的连接。
数据管家可以为某个领域认领表。 认领是独占的：一张表只属于一个领域。认领是把基础设施与模型连起来的受治理操作。
数据管家可以基于领域资产创建域内视图。 视图在数据管家拥有的同一领域内的资产之上表达业务逻辑，例如联接、聚合和派生指标。视图会创造新的语义，需要数据管家批准。
分析师可以基于已批准的关系创建跨域查询。 查询是用任何受支持查询语言编写的跨域视图。它们不创造新的语义，只遍历已批准的关系路径。不需要额外批准，因为治理在更早的关系层和列可见性层就已发生。执行规则的是目录：编译器会拒绝任何不在已批准关系目录中的遍历。
任何人都可以申请访问领域资源。 访问权按资源授予，从不按查询授予：只要能访问某个资源，就可以查询它。治理在执行时由处理管道强制执行。

资源：表和视图作为对等实体¶

表和视图的区别只在于来源：表从数据源认领，视图由数据管家定义。一旦成为领域资产，治理模型就对两者一视同仁：

两者本身都是领域资产，在目录中可见
两者都可以成为关系的目标
两者都可以根据原则6被授予
两者都受同一治理管道约束

数据管家可以私下认领表，只公开经过整理的视图作为面向公众的数据产品。

视图组合¶

视图始终只属于一个领域。视图只有一种，而且总在领域之内。视图的存在有两种目的之一：

跨域导入——数据源位于领域之外。跨域数据只能通过视图进入某个领域，视图充当只读适配器，将外部数据命名为该领域的业务概念。
本地派生——数据源属于同一领域。视图从现有领域资产派生出新的或计算得出的数据。新的或派生的数据只能以视图形式存在。

视图可以引用：

同一领域内已认领的表
根据字段访问授权，从其他领域导入的字段
同一领域内的另一个视图，前提是该变化具有明确目的：字段限制、聚合，或通过额外联接进行扩充

视图能嵌套多深，没有任何技术限制。质量把关靠的是数据管家在 HITL 审查中的判断。

每个视图都带有在创建时声明的业务用途：

属于受治理构件的一部分，因此数据管家在了解视图用途的情况下作出批准
根据原则7，在访问请求中被引用，以便数据管家评估其适用性
从视图创建之时起，贯穿整个治理工作流程

查询¶

查询沿着已批准的关系路径遍历领域资产。与视图不同，它不创造新的语义，只遵循模型已批准的结构。查询可以用任何受支持的查询语言编写（SQL、GraphQL、Cypher）。

结构化强制： 由关系目录来强制执行。编译器会把每次遍历与已批准的目录条目比对，并拒绝引用未批准路径的查询。治理内建于结构之中，所以运行时不另做检查。

无需批准： 治理在更早的关系层和列可见性层就已发生。只要用户能看到这些列、遍历路径已获批准，这个查询就是合规使用，没有其他关卡。

与视图的区别：

视图：域内、引入新的语义含义、由数据管家整理
查询：遍历已批准的关系、无新语义、无批准关卡

按查询语言划分的领域表达方式：

每种受支持的语言都以其原生的结构化命名空间来表达领域：

语言	领域表达方式	示例
GraphQL	类型和字段名称前缀	`type sales__Order { ... }`, `query { sales__orders { ... } }`
SQL	架构 (Schema) 名称	`SELECT * FROM sales.orders`
Cypher	额外节点标签（仅当类型名称含糊不清时才需要指定领域）	`MATCH (o:Sales:Order)`

编译器根据这些结构位置推断领域归属，所以无需任何注解或提示。

关系¶

关系是两个资产之间一条已获批准的遍历路径。领域边界不改变关系的本质，只决定由谁来批准。

批准：

关系请求由它涉及的域决定：其源表所在的域和目标表所在的域
只有创建关系的权利覆盖其中某个域的用户，其批准才计数；任何这样的用户都可以拒绝
当两位不同的用户（均非请求者）批准、且每个涉及的域都有一位批准者后，请求即被执行：跨两个域的关系需要每一方的同意，单个域内的关系需要该域的两位批准者
批准一项关系会构建每位数据管家的依赖关系图，这样数据管家能在架构变更生效前得知

关系在有人需要时才创建，从不预先投机创建。第一个有业务需求的团队完成这项工作，后来的团队直接沿用。

对优化的影响： 关系声明既是治理产物，也是对联接形态的结构化描述。定义一个关系的两张表、两列和联接类型，正是查询优化器预先物化该联接所需要的。跨数据源的关系会自动获得预物化的联接表，同一数据源内的关系可以通过 materialize: true 选择启用。认真思考并批准有效关系的数据管家，会直接得到更快的查询：治理工作和优化工作是同一件事。

字段访问授权¶

字段访问授权是从一个领域授予另一个领域的许可：领域 A 可以在自己的视图中使用领域 B 的特定字段。

授权生命周期：

当创建视图时识别出需要外部字段，便会触发该授权
由目标领域的数据管家批准一次
属于发出请求的领域，而非触发该授权的视图
请求领域内后续的任何视图，均可使用已授权的字段，无需进一步的跨域参与
额外未获授权的字段需要提出新的申请

使用后通知： 用已授权字段创建视图时，会通知来源方的数据管家，但不要求其批准。通知包含视图名称、声明的业务用途、使用的字段，以及批准它的数据管家。这让来源方的数据管家获得：

可见性——了解其数据的使用情况
监督权——如果使用方式看起来不合适，有依据提出关切
追索权——可以撤销授权，使相关联的视图失效

其权衡在于：源领域在批准字段访问权限时，并不了解日后的每一种使用方式。逐视图批准在理论上是正确的，但在实践中不可行。

查询创建工作流程¶

三个阶段，按顺序进行。

阶段1 — 塑形（SQL探索，从关系页面开始）：

分析师从关系页面打开塑形工具，用原始SQL试验联接路径
SQL会在可访问的数据上执行，并受制于现有的行级安全和列掩码
SQL中的JOIN会被解析，并呈现为候选关系建议
机器建议的候选项（外键推断、语义推断）会与分析师的SQL一并显示在同一视图中
分析师选择要提升为正式关系请求的候选项

阶段2 — 关系批准（影响重大——具有结构性且永久）：

由该关系涉及的领域决定，见关系
这是一条合理的遍历路径吗？这个联接在语义上成立吗？
需要两位不同的用户批准，且都不是申请人，并且每个相关领域都要有一位批准人；之后该关系成为目录中的永久条目

阶段3 — 查询创建：

分析师以任意受支持语言（SQL、GraphQL、Cypher）构建查询，遍历已批准的关系路径
只有目录中已批准的关系才可被遍历，编译器以结构化方式强制执行这一点
无需批准：列可见性和关系批准是仅有的关卡

以HITL作为主要控制手段¶

技术规则处理客观的部分：字段来源追踪、领域边界强制和编译器校验。依赖上下文的判断留给数据管家。诸如视图组合深度、每个查询的声明用途、关系审批决定之类的限制，属于 HITL 范畴，编译器并不强制。

源领域中立性： 源领域的数据管家只需批准一次该关系，以及批准一次该字段授权。此后，下游领域便可在该授权界限内运作：

在跨越边界的决策时高度审慎
此后通过通知和查询历史记录轻量了解

2. 可发现性¶

发现层级¶

发现按治理程度递增分为五个层级。每个层级都是下一层级的先决条件。

层级	描述	治理状态
1 — 已注册数据源架构	已注册数据源中的每张表、每个列及类型。属于管理员级别的可见性。	无——原始清单
2 — 未认领表	从已注册数据源内省得到、没有领域所有者的表。可被有权访问该数据源的数据管家看到。	可用但未经治理
3 — 领域资产	已认领的表及数据管家定义的视图。完全受治理、有明确所有权、在目录中可见。	完全受治理
4 — 关系	第3层资产之间已批准的遍历路径。是创建跨域视图的先决条件。	由双方数据管家批准
5 — 字段授权	领域对领域的字段访问权限。是最具体、最审慎的受治理访问方式。	由源数据管家批准

未认领的表意味着存在缺口。如果所需数据只存在于第 2 层，必须先由数据管家认领，治理才能继续。如果所有层级都没有候选，请上报管理员。

外键约束¶

外键约束属于单个数据源，因此不能跨数据源。跨数据源的联接路径完全来自目录中已批准的关系（第 4 层），这类证据更强，因为双方数据管家都已验证过。

在同一数据源内：

外键约束会在数据源注册时自动呈现为候选关系
它们代表明确的建模意图：在大多数分析型SQL系统中并未强制执行，但属有意声明
候选项要成为已批准的关系，仍需数据管家验证

关系置信度层级¶

证据	置信度
已批准的目录关系——跨数据源、经双方数据管家验证	最高
数据源内部外键约束——明确建模意图，未强制执行但属有意	高
数据源内部语义推断——在一致的架构内，列名/类型相似	中
跨数据源语义推断——不同系统间的命名惯例存在差异；误判风险高	低

由多种证据类型相互印证的建议，其置信度会随之提升。

数据探查与相关性分析¶

对于以语义方式推断的候选项，数据探查提供了一个验证步骤：

值重叠度——源列的值出现在目标列中的比例
基数——分布是否符合预期的关系类型
空值率——源列为空值的比例，反映其可选性

相关性高会提升置信度，相关性低则会压制或降级该候选。探查只能佐证，不能证明。整数范围可能碰巧重叠，分析系统里部分引用完整性也很常见，所以出错的余地很大。数据管家的语义判断才是唯一可靠的最终检查。

LLM辅助发现¶

LLM会同时在全部五个层级上运作，按置信度对关系、候选认领及遍历路径进行排序建议。

LLM呈现的内容：

按置信度排序的候选关系
可能满足数据需求的未认领表，并提示启动认领流程
若无任何候选项，即为升级至管理员的信号

根据业务描述进行视图设计：

分析师提供自然语言描述及可选约束条件。LLM会生成建议的视图结构。

输入：

业务描述：实体、指标、关系、意图
可选约束条件：过滤器、时间窗口、聚合、排除字段、敏感度限制

示例：

"过去30天按交易对手划分的每日交易量，仅限活跃交易对手，并显示交易对手法定名称及信用评级。不含个人身份信息。"

LLM处理流程：

解析——识别实体、指标、维度、过滤器、排除项
搜索——在所有目录层级中查找匹配的资产
建议——领域资产、关系、字段、聚合结构
评分——根据层级证据对每个组件评定置信度
先决条件——所需认领、关系及字段授权的有序清单
缺口——任何层级均无候选项的实体或字段，标记以升级至管理员处理

输出：

供分析师审阅和调整的查询草稿
每个组件的置信度分数
有序的先决条件清单
缺口清单

一旦视图正式创建，业务描述便会成为该视图声明的业务用途。

以SQL为先的关系发现（建模工具）：

它以模态框形式从关系页面打开。用途是构建语义模型：在把结构性的联接路径正式定为受治理的关系之前，先把它们找出来。

分析师针对可访问的表编写自由SQL（行级安全和掩码仍会生效）
系统解析SQL的AST，每个JOIN条件都会成为候选关系建议
候选项清单会与机器建议的候选项（外键推断、语义推断）一并显示，以便统一审阅
分析师将所选候选项提升为正式关系请求
已批准的关系会被添加到目录中，并可在查询中被遍历

在您梳理结构时，建模工具可能会显示所有已注册的表，包括分析师看不到其数据的表。模式可见性是另一回事；对数据本身的访问由数据管家的批准来管控。

3. 使用情况¶

查询审计轨迹¶

任何触及领域资产的查询，都会记录在仅可追加的 query_audit_log 中。每条记录均包含：

tenant_id、user_id、role_id——身份上下文
查询的SHA-256哈希值；绝不会存储查询的原始文本
table_ids——该查询所触及的领域资产
source、status_code、duration_ms
logged_at——时间戳

该日志仅可追加（数据库层级已阻止 DELETE 和 UPDATE），并按 (tenant_id, logged_at) 和 (user_id, logged_at) 建立索引。

数据管家的查询历史报告是基于此日志的聚合视图，可按资产、角色和时间窗口筛选。这让目录成为一个实时的治理工具：数据管家在使用发生时就能看到自己的资产如何被使用，而不是事后才知道。

两种可见性机制：

推送（Push）——针对结构性行为的使用后通知（例如有人使用您的字段创建了新视图）
拉取（Pull）——查询历史记录，用于了解运行时的使用模式