workspace/code/fms/FMS元数据驱动架构重构方案.md

FMS 元数据驱动架构整体重构方案

文档版本：V0.1（方案草案）
编制日期：2026-10-10
范围：元数据模型、模块配置、模块运行时及相关数据库结构
状态：待评审，尚未实施

1. 结论摘要

本次重构保留并强化元数据驱动这一核心概念。模块定义、字段语义、关系、页面视图和通用行为由元数据描述，通用运行时读取已发布的元数据运行；列表、查询、保存、权限、关系、工作流和公式等能力统一通过通用接口执行，复杂逻辑由 SQL、函数库和业务处理器补充。

项目属于草稿 / Demo 阶段，不要求兼容现有元数据表结构和配置 JSON。可以重做元数据数据库，并整体替换配置和运行时主链路；不需要新旧格式长期双写或并行维护。

物理数据源与表结构 → 模块元数据 → 模板 / 默认值 → 校验 / 编译 / 发布
                                                    ↓
                       统一模块运行时 + 通用代码协议 → SQL 业务表 / 视图

SQL Server 中的真实业务表和视图继续作为业务数据事实来源。元数据描述如何理解、呈现和操作这些数据，通用 SQL、函数库和业务处理器协议可以补充复杂逻辑；不采用 EAV 存储所有业务记录，也不让元数据引擎任意生成业务表。

2. 重构目标与边界

• 元数据仍是通用模块的运行时核心，不退化为页面备注或少量展示配置。
• 常见模块通过数据源、模板和少量字段选择即可完成基础配置。
• 一个字段只定义一次；列表、表单、查询、详情等视图引用字段，不重复维护语义。
• 默认配置可推导、可重复生成；用户明确调整过的配置不被覆盖。
• 元数据发布前经过统一校验，运行时消费同一份有效定义。
• 元数据数据库可以整体重做，不受 s_module、s_field、s_module_schema 现有结构约束。
• 列表、查询、保存、权限、关系、工作流和公式均提供元数据默认实现，并保留统一 SQL / 函数库 / 业务处理器协议。
• 后端通过通用接口绑定 SQL、函数和处理器，不为具体模块增加特殊 API，也不在元数据中保存可执行代码。
• 不将所有字段值改为 EAV 或通用 JSON；业务表仍通过 SQL migration / 数据库变更管理。
• 不建设可执行任意脚本的规则引擎，不把库存、财务、结算等复杂事务强行塞进配置；复杂逻辑通过受控的代码扩展实现。
• 不为本次目标无差别重写认证、文件、导出等稳定模块，只调整必要集成点。
• 不要求兼容旧元数据格式；需要保留的 Demo 数据可一次性导入，否则重建 / 播种。

3. 总体架构

┌──────────────────── 配置面 ────────────────────┐
│ 元数据工作台 → 草稿定义 → 校验 / 预览 → 发布版本 │
└────────────────────────┬───────────────────────┘
                         ↓
                  元数据目录 / 发布快照
                         ↓
┌──────────────────── 运行面 ────────────────────┐
│ 元数据解析与缓存 → 查询 / 保存 / 权限 / 页面渲染 │
└────────────────────────┬───────────────────────┘
                         ↓
             SQL Server 表、视图与只读查询 SQL
                         ↓
            统一模块接口、SQL、函数库及业务处理器

配置面

工作台负责选择数据源、导入物理字段、指定业务语义、应用模板、调整视图并预览。编辑内容为草稿，通过校验后才能发布。

元数据编译与校验

后端维护权威校验与解析逻辑。发布时将模块定义、模板默认值和用户覆盖项合成为有效定义，并检查字段引用、数据源、视图、关系和查询条件。前端预览使用后端返回的有效定义，避免前后端分别推导默认规则。

运行面

后端只提供统一的模块接口。统一接口读取已发布的 ModuleDefinition，负责列表、查询、保存、权限、关系、工作流和公式等通用能力；查询值参数化，保存和动作在统一事务上下文中执行。SQL、公式函数和业务代码作为通用接口内部的实现来源，不为每个模块新增专用 API。

通用接口与代码控制

每项能力都遵循同一套调用方式：

1. 元数据提供模块、字段、视图、关系和默认规则。
2. 通用接口根据模块定义执行默认列表、查询、保存、权限、关系、工作流和公式逻辑。
3. 需要代码控制时，在通用接口内部调用统一的 SQL、函数或业务处理器协议；调用方式不随模块变化。

能力	元数据默认职责	代码扩展或接管职责
列表	数据源、字段、过滤、排序、分页和列展示	自定义查询、聚合、行转换和复杂数据范围
查询	条件字段、操作符、条件组和参数定义	特殊条件解析、跨表查询和只读 SQL
保存	标准增删改、字段校验、主键和关系处理	事务编排、状态流转、库存扣减和保存前后钩子
权限	模块、字段、角色和数据范围声明	上下文权限判断、动态授权和特殊拒绝规则
关系	主从、引用、多对多和加载规则	复杂关联加载、级联校验和同步逻辑
工作流	节点、连线、参与者和状态定义	审批条件、业务动作、会签规则和外部调用
公式	表达式、字段依赖和受限通用函数	通用函数库、复杂计算、跨单据取数和异步计算

代码实现通过后端统一注册表或 SQL 目录管理，不在数据库中保存 Java 类名、脚本或任意可执行内容。通用权限约束不能被业务代码绕过；业务代码可以补充通用接口的规则。模块只声明需要的标准能力和参数，不声明专用接口。

4. 元数据逻辑模型

运行时使用统一逻辑对象 ModuleDefinition。它是稳定契约，不要求与单张数据库表或单个 JSON 一一对应。

模块

包含稳定编码、名称、多语言键、类型、状态、组织层级、查询数据源、标准保存目标 / 主键、数据范围字段、字段、关系、视图、模板和发布版本。模块类型收敛为少数明确类别，如标准数据、只读查询、业务动作模块。

字段

区分物理事实和业务语义：

• 物理事实：来源表 / 视图、列名、SQL 类型、长度、精度、可空性等，优先由数据库结构检查得到，不重复手工维护。
• 业务语义：标签、多语言键、语义类型、关联目标、是否可编辑 / 列表展示 / 查询 / 排序 / 导出等，由元数据表达。
• 界面属性：控件、宽度、格式等仅在需要覆盖默认值时配置。

字段使用模块内稳定编码；视图引用字段编码，不复制物理属性和业务语义。

关系、视图与行为

• 关系元数据表达主从、引用和多对多关系，包含源 / 目标模块字段及规则，发布时校验完整性。
• 表单、列表、查询、详情是不同视图类型，只保存顺序、分组、布局、列宽、排序、操作符等视图特有信息；布局采用可读、可校验的结构化定义，不保存画布坐标。
• 字段参与视图的默认状态由字段能力、模板和默认策略推导；个性化差异作为显式覆盖。
• 简单校验和通用 CRUD 可由元数据表达；复杂业务动作映射到稳定的后端处理器编码。
• 列表、查询、保存、权限、关系、工作流和公式通过统一模块接口接入；这些能力引用模块定义和已发布快照，不为每个模块建立特殊接口。

5. 元数据数据库重构

以下是逻辑实体职责，最终表名和列定义在元数据契约评审后确定。可重做元数据表结构，但业务记录仍存放于真实 SQL 表。

逻辑实体	职责	建议存储
模块	身份、类型、状态、树结构、数据源和通用运行参数	规范化关系表
模块字段	字段编码、物理映射、业务语义、能力标记	规范化关系表；模块内编码唯一
模块关系	关系类型及源 / 目标字段	规范化关系表；发布时校验引用
模块视图	表单、列表、查询、详情及布局	s_module_schema，按视图类型保存受校验 JSON
模板	默认字段能力、视图结构、推荐规则	可版本化定义
发布版本	不可变快照、版本号、校验结果、发布时间	版本记录；运行时按已发布版本读取

推荐目标表结构

建议继续使用现有的 s_ 前缀和核心表。后端是通用接口，因此不再为数据源、视图和代码扩展分别增加运行时表：模块数据源保留在 s_module，视图 JSON 保留在 s_module_schema，复杂代码由后端统一实现和注册。只新增发布版本和快照表解决草稿与运行态隔离。

目标实体	关键字段 / 组成	说明
模块 s_module	模块编码、父级、名称、多语言键、模块类型、查询/保存来源、主键、数据范围和默认排序	保留当前模块主表，清理无约束的大 JSON；数据源由通用接口读取
模块字段 s_field	模块、字段编码、来源类型、来源名称/别名、名称、多语言键、语义类型、字段能力、启用状态	支持物理列、查询别名、计算字段和虚拟字段；物理 SQL 类型仍优先从数据库读取
模块视图 s_module_schema	模块、视图类型、结构版本、b_schema_json	JSON 保存分组、字段引用、列属性、查询条件、控件和公式；发布时统一校验
模块关系 s_relation	关系编码、源/目标模块字段、关系类型、用途、基数、加载规则、删除策略	发布时校验模块和字段引用，保留现有删除语义
模块版本 s_module_version	模块、版本号、草稿/已发布/废弃状态、校验摘要、发布人、发布时间	管理草稿与当前有效版本边界
发布快照 s_module_snapshot	版本、编译后的 ModuleDefinition、快照摘要、生成时间	运行时只读取不可变快照，不直接读取编辑态表
模板及模板版本 s_template / s_template_version	模板编码、版本、默认字段能力、视图 JSON、推荐规则	模板是可编辑初始值，不是硬编码页面
用户偏好 s_user_module_pref	用户、模块、视图、相对默认值的覆盖	可选保留，只能改变布局偏好，不能改变语义、权限或数据源

s_module_schema.b_schema_json 不是无约束 JSON：必须包含 schemaVersion，只能引用本模块已登记的字段和关系，并由后端 JSON Schema 和发布校验共同约束。编辑态以 s_module_schema 为事实来源，发布后编译成 s_module_snapshot。

推荐 DDL（示例）

create table dbo.s_module (
    b_id varchar(80) not null primary key,
    b_parent_id varchar(80) null,
    b_depth int not null default 0,
    b_path varchar(1500) not null,
    b_name nvarchar(200) not null,
    b_i18n varchar(150) null,
    b_module_type varchar(20) not null, -- module / data / virtual
    b_view_table varchar(256) null,
    b_save_table varchar(256) null,
    b_key_field varchar(80) null,
    b_scope_field varchar(80) null,
    b_order_sql varchar(500) null,
    b_query_sql nvarchar(max) null,
    b_config_json nvarchar(max) null,
    b_canuse tinyint not null default 1,
    b_xh int not null default 0,
    b_bz nvarchar(2000) null,
    b_updated_by varchar(50) null,
    b_updated_at datetime2 null
);

create table dbo.s_field (
    b_module_id varchar(80) not null,
    b_field varchar(80) not null,
    b_source_type varchar(20) not null, -- physical / alias / computed / virtual
    b_source_name varchar(256) null,
    b_name nvarchar(200) not null,
    b_i18n varchar(150) null,
    b_semantic_type varchar(40) not null,
    b_can_read tinyint not null default 1,
    b_can_edit tinyint not null default 0,
    b_can_filter tinyint not null default 0,
    b_can_sort tinyint not null default 0,
    b_can_export tinyint not null default 0,
    b_canuse tinyint not null default 1,
    b_xh int not null default 0,
    primary key (b_module_id, b_field)
);

create table dbo.s_module_schema (
    b_module_id varchar(80) not null,
    b_schema_type varchar(20) not null,  -- view / edit / query / detail
    b_schema_version int not null default 1,
    b_schema_json nvarchar(max) not null,
    b_canuse tinyint not null default 1,
    b_updated_by varchar(50) null,
    b_updated_at datetime2 null,
    primary key (b_module_id, b_schema_type)
);

create table dbo.s_relation (
    b_relation_code varchar(100) not null primary key,
    b_source_module_id varchar(80) not null,
    b_source_field varchar(80) not null,
    b_target_module_id varchar(80) not null,
    b_target_field varchar(80) not null,
    b_relation_type varchar(30) not null, -- one_to_one / one_to_many / many_to_one
    b_usage varchar(30) not null,         -- reference / detail / selector / load
    b_load_mode varchar(20) not null default 'lazy',
    b_on_delete varchar(20) not null default 'restrict',
    b_canuse tinyint not null default 1,
    b_xh int not null default 0
);

create table dbo.s_module_version (
    b_id varchar(100) not null primary key,
    b_module_id varchar(80) not null,
    b_version_no int not null,
    b_status varchar(20) not null, -- draft / published / retired
    b_checksum varchar(128) null,
    b_published_by varchar(50) null,
    b_published_at datetime2 null,
    b_created_by varchar(50) null,
    b_created_at datetime2 not null default sysdatetime(),
    unique (b_module_id, b_version_no)
);

create table dbo.s_module_snapshot (
    b_version_id varchar(100) not null primary key,
    b_module_id varchar(80) not null,
    b_snapshot_json nvarchar(max) not null,
    b_checksum varchar(128) not null,
    b_created_at datetime2 not null default sysdatetime()
);

create table dbo.s_user_module_pref (
    b_user_id varchar(50) not null,
    b_module_id varchar(80) not null,
    b_schema_type varchar(50) not null,
    b_preference_json nvarchar(max) not null,
    b_updated_at datetime2 null,
    primary key (b_user_id, b_module_id, b_schema_type)
);

模板表沿用相同原则：s_template 保存模板身份，s_template_version 保存版本、默认字段能力和视图 JSON；模板应用只是生成模块草稿，不直接成为运行时配置。

create table dbo.s_template (
    b_id varchar(80) not null primary key,
    b_name nvarchar(200) not null,
    b_template_type varchar(30) not null, -- master_data / document / detail / readonly
    b_canuse tinyint not null default 1
);

create table dbo.s_template_version (
    b_id varchar(100) not null primary key,
    b_template_id varchar(80) not null,
    b_version_no int not null,
    b_default_fields_json nvarchar(max) not null,
    b_views_json nvarchar(max) not null,
    b_extensions_json nvarchar(max) null,
    b_status varchar(20) not null, -- draft / published / retired
    b_created_at datetime2 not null default sysdatetime(),
    unique (b_template_id, b_version_no)
);

推荐补充以下约束和发布检查：

• s_field.b_module_id、s_module_schema.b_module_id、s_module_version.b_module_id 必须引用存在的模块；模块树字段由业务层校验不能成环。
• s_module 的数据源字段由模块类型和通用接口校验组合有效性；查询 SQL 只允许用于受控的只读查询，排序字段必须来自字段定义。
• s_module_schema.b_schema_json、s_module.b_config_json 和模板 JSON 使用 ISJSON 做基础检查，并由后端 JSON Schema 检查 schemaVersion、字段引用和关系引用。
• s_module_snapshot、已发布的 s_module_version 和已发布模板版本不可原地修改；回滚通过切换当前有效版本完成。
• 动态业务表不因为元数据引用而强制建立数据库外键；元数据内部引用使用外键或等效约束，跨 JSON 引用由发布校验保证。

Demo 数据示例

以下示例定义一个客户资料模块，业务事实表为 b_othercompany，只读查询视图为 v_b_othercompany：

s_module
  base.customer       → 基础资料 / 客户资料 / data / v_b_othercompany / b_othercompany / b_id

s_field
  base.customer.b_ywid       → physical / b_ywid / 客户编码 / code / read+edit+filter+sort
  base.customer.b_name       → physical / b_name / 客户名称 / text / read+edit+filter+sort
  base.customer.b_owner_id   → physical / b_owner_id / 业务员 / user_reference / read+edit+filter

s_module_schema
  base.customer / list       → schema JSON：列、宽度、排序
  base.customer / form       → schema JSON：分组、控件、必填、公式
  base.customer / query      → schema JSON：条件字段、组件、操作符

列表 JSON 示例：

{
  "schemaVersion": 1,
  "columns": [
    { "field": "b_ywid", "visible": true, "width": 140, "sortable": true },
    { "field": "b_name", "visible": true, "width": 220, "sortable": true },
    { "field": "b_owner_id", "visible": true, "width": 120 }
  ],
  "defaultSort": [{ "field": "b_name", "direction": "asc" }]
}

现有表到目标表的改造映射

• s_module.b_view_table、b_query_sql、b_save_table、b_key_field、b_scope_field、b_order_sql 继续由 s_module 保存；删除或收紧无约束的 b_config_json 内容。
• s_field 保留模块字段身份，并补充来源映射、语义类型和能力标记；列表、表单、查询的顺序和显示属性保留在对应 s_module_schema.b_schema_json 中。
• s_module_schema.view/edit/query 保留为视图配置的主要存储格式，增加 b_schema_version 和后端 JSON Schema 校验。
• s_relation 保留已有源/目标字段和删除策略，增加稳定关系编码、用途、加载规则等字段；历史关系先一次性导入，再由发布校验补足引用检查。
• 现有模块配置可通过一次性导入工具转换；不在新旧表之间长期双写，也不让旧表继续作为第二事实来源。

不需要整体重做的表

• 真实业务表和业务视图继续由 SQL migration 管理，不因为元数据重构而改成 EAV 或通用 JSON。
• wf_definition、wf_version、wf_binding 及工作流运行表可继续使用；wf_binding 需要改为引用模块的已发布版本或在发布时校验模块版本。
• 现有权限主体和授权表可以保留；权限运行时通过通用接口读取已发布字段和模块定义。
• 公式不要求新增业务数据表；简单公式随模块快照发布，复杂函数由通用公式接口调用后端函数库。

对现有核心表的评估

结论：需要重构元数据配置表，但不需要仅因配置器难用而整体重做所有业务数据表。 当前表结构能表达基本模块、字段和关系；主要问题是职责混放、字段能力分散到视图 JSON，以及缺少可发布的版本边界。

• s_module：继续保存模块身份、树结构和默认数据源，因为后端统一通过模块接口读取这些定义；b_config_json 只保留少量经过 schema 校验的低频配置，模块草稿 / 发布时间由版本模型管理。
• s_field：当前主要保存名称、业务类型、启用和顺序，尚未明确区分物理列、查询别名、计算 / 虚拟字段。建议增加明确的字段来源种类与来源映射、语义类型和模块级能力；数据库物理类型由 SQL Server 结构检查获得。表单 / 列表 / 查询中的显示顺序和控件差异放到对应视图字段配置，不塞回字段主定义。
• s_module_schema：继续按 view/edit/query 保存视图 JSON，增加结构版本和发布校验；不新增 s_module_view、s_module_view_group 或 s_module_view_field。
• s_relation：保留关系作为独立元数据，但建议引入稳定关系编码 / 标识，显式描述关系用途、基数、展示 / 加载规则，并对模块和字段引用建立数据库约束。现有删除策略等已表达的业务含义应迁移保留，不因改表而丢失。
• s_user_module_pref：如保留个性化配置，只允许保存列表列、查询布局等用户偏好覆盖，不得改变模块字段语义、数据源、权限或保存行为。若 Demo 暂无真实个性化需求，可先不纳入新核心模型。
• 新增发布版本实体：使用 s_module_version 保存草稿与已发布版本的边界，使用 s_module_snapshot 保存不可变运行快照；发布失败不替换当前有效版本。
• 代码扩展：不新增模块扩展绑定表；后端统一接口通过 SQL 目录、公式函数库和通用业务处理器协议调用代码实现，模块只使用通用参数和元数据配置。

元数据表之间应使用主键、唯一约束和可表达的外键保障内部引用完整性，并用发布校验补足跨 JSON / 动态数据源的检查。不要为了引用元数据而给所有动态业务表强行建立数据库外键。

规范化与 JSON 边界

• 模块、字段、关系、版本等有稳定身份、查询和引用的对象采用关系表。
• 表单布局、列表列布局、查询 UI、公式和少量扩展属性继续存 JSON，但其中只能引用已定义字段和关系；JSON 必须带 schemaVersion 并通过结构校验。
• 发布快照可采用 JSON 作为编译产物，不作为编辑态唯一事实来源。
• 对模块编码、模块内字段编码、模块 / 视图类型、版本号等建立唯一约束；可表达的元数据引用建立外键或等效约束，并由发布校验再次检查。
• 明确删除、改名和关系变更策略，不依赖前端操作顺序保证一致性。
• 不将业务字段值存入 entity_id / field_id / value 三元 EAV 表；不把所有配置塞进单个无约束 JSON。
• 不复制 SQL 物理列定义后再要求长期人工同步；物理结构优先读取，元数据维护业务语义。

草稿、发布与回滚

建议区分编辑草稿与当前发布版本。草稿保存不改变运行中配置；发布时完成校验、生成不可变快照并原子切换当前版本。保留基本发布历史用于问题定位和回滚。Demo 第一版不建设复杂审批、多用户锁或多环境发布平台。

6. 配置体验

配置流程采用“默认优先、逐步展开”：

1. 选择模块模板和数据源类型。
2. 选择表 / 视图，读取物理字段并映射业务语义。
3. 确认字段能力，自动生成表单、列表、查询初始定义。
4. 预览常用页面，再按需进入结构化的高级视图配置。
5. 运行发布校验，通过后发布。

首批模板建议包含基础资料、单据主表、明细表、只读查询 / 报表。模板提供可编辑初始值，不是硬编码页面。

不采用拖拽式设计器

表单和列表不再采用画布式拖拽设计器，也不保留绝对坐标 / 自由定位配置。拖拽交互难以精确、重复配置，布局结构也不利于阅读、差异比较和长期维护。

• 表单：采用模板、分组和字段清单配置。通过字段选择、分组设置、列数 / 排序等结构化属性定义布局；字段顺序使用排序值或批量排序操作，不依赖画布拖动。
• 列表：采用列配置表 / 字段矩阵，集中设置是否显示、顺序、宽度、格式、对齐、排序和汇总等属性；支持批量添加、移除和套用模板。
• 预览：配置面板旁提供实时预览，但预览仅用于检查结果，不作为拖放编辑画布。
• 元数据：保存语义结构和字段引用，不保存像素坐标、拖拽路径或依赖编辑器内部实现的状态。
• 高级场景：通过分组、布局模板、字段显示规则及通用接口配置解决；不以重新引入自由拖拽作为兜底。

默认规则：

• 根据 SQL 类型推导候选字段类型和控件；语义不明确时要求确认，不做危险猜测。
• 根据业务语义推导筛选组件、操作符、格式和建议列宽。
• 新增字段补默认配置；已显式调整的配置不被重置；重置需显式操作。
• 默认生成必须幂等，同一输入重复应用不产生重复节点或配置漂移。
• 字段能力集中在矩阵中维护；布局通过模板、分组和排序等结构化配置调整，不使用拖拽画布。

7. 现状与重构方向

当前模块配置将字段、列表、表单、查询拆成不同面板，字段参与状态会修改多份界面 JSON；现有表单 / 列表设计器还采用拖拽式交互。本次重构不迁移现有画布和拖拽实现，改用模板、字段矩阵、分组 / 排序表格及实时只读预览。项目已有类型默认值和列表—查询联动逻辑，可保留其业务规则并重新组织。

• fms-vue/src/views/module/module-management/ModuleFieldsPanel.vue:3：字段定义与表单 / 列表 / 查询参与关系。
• fms-vue/src/views/module/module-management/components/fieldDefaults.js:1：列表和查询默认值规则。
• fms-vue/src/views/module/module-management/components/design-editor/common/schemaModel.js:540：视图字段节点新增 / 移除。
• fms-vue/src/views/module/module-management/index.vue:1431：配置面板分区导航和绑定。

重构保留已验证的行为意图，但不要求保留当前组件边界、JSON 结构或数据库表结构。

8. 整体重构范围与顺序

不做新旧格式长期并行或渐进兼容；按依赖顺序拆分实施任务，便于验证：

1. 确定元数据契约：模块类型、字段语义、关系、视图、默认覆盖、发布和通用接口契约。
2. 重建元数据数据库：调整模块、字段、视图 JSON 和关系表，新增版本与快照表，补充主键 / 唯一约束 / 引用约束；决定 Demo 配置重建还是一次性导入。
3. 实现后端目录与编译器：读取物理结构、校验字段和视图 JSON、默认合成、生成快照、发布、版本切换、缓存失效和回滚。
4. 替换配置工作台：数据源检查、字段导入、模板初始化、能力矩阵、预览、发布。
5. 替换运行时消费链路：列表、查询、表单、保存统一读取发布定义。
6. 接入通用能力：在统一模块接口中接入列表、查询、保存、权限、关系、工作流和公式的标准实现，并接入统一 SQL、函数库和业务处理器协议。
7. 删除旧路径：完成一次性导入或确认弃用后，删除旧 s_module_schema JSON 结构适配和重复逻辑；保留新格式下的同一张表作为唯一视图配置来源。

虽然不需要渐进兼容，仍建议用一个基础资料、一个主从单据、一个只读查询模块验证新契约，再批量建立 Demo 配置。这是新架构验收，不是要求新旧架构并行运行。

9. 验收标准

• 新建基础资料模块，无需分别手工搭建字段、表单、列表和查询的基础配置。
• 表单和列表均可通过结构化配置完成，不需要拖拽画布、绝对坐标或依赖设计器内部状态。
• 列表列和表单字段可以通过清单 / 矩阵批量配置、排序和复用模板，配置差异可读、可校验。
• 模块字段只有一个权威定义；多个视图引用字段，不重复维护语义。
• 默认配置可重复生成，且不覆盖显式配置。
• 无效字段引用、数据源列缺失、关系目标错误、非法查询规则在发布时给出明确错误。
• 运行时只消费已发布版本；发布失败不影响当前可用版本。
• 编辑态使用模块、字段、视图 JSON 和关系表；运行态使用对应的不可变发布快照。
• 列表、查询、保存、权限、关系、工作流和公式均可使用元数据默认实现，并可通过统一 SQL、函数库和业务处理器协议补充复杂逻辑。
• 统一接口的参数、字段引用和依赖关系在发布时校验；接口执行失败有明确错误和审计信息。
• 简单 CRUD 使用通用运行时；复杂业务动作由明确的后端处理器完成。
• 真实 SQL Server 业务表仍是业务数据事实来源，不引入 EAV 业务数据主存储。
• 旧元数据路径已删除或仅作为一次性导入工具，不存在双重事实来源。

10. 需要同步修订的文档

目前架构文档存在方向冲突：部分草案提出以业务域代码包取代元数据运行时，而本方案采用元数据主导、通用接口承载复杂逻辑的模式。本方案评审通过后应统一修订：

• FMS新系统核心架构设计.md：明确元数据运行时是通用能力核心，业务域代码通过统一模块接口、SQL 和业务处理器协议接入复杂逻辑。
• FMS新系统核心架构实施计划.md：增加元数据数据库、编译器、工作台、运行时和通用接口实现任务。
• FMS新系统核心表结构设计.md：重新定义元数据表，不再将现有 s_module、s_field、s_module_schema 作为不可变前提。
• 开发规范.md：明确元数据契约、发布定义、查询 / 保存边界和通用接口约定。

11. 假设与待定项

• 暂保留 SQL Server 作为数据库目标；允许重做元数据表，不主动改变租户数据库路由模式。
• 元数据和 Demo 配置可重建；是否保留样例数据，实施前决定重建或一次性导入。
• 本文确定架构方向，不冻结最终 DDL、API、类名或 Vue 目录；这些在元数据契约评审后设计。
• 需要确定权限、工作流、公式、多语言及通用接口实现是否随模块发布版本整体冻结，并定义接口版本兼容、事务边界、错误模型和规则优先级。