领域模型原则¶

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）——查询历史记录，用于了解运行时的使用模式