让企业真正拥有自己的低代码平台
以业务数据建模为核心，让企业应用从快速交付走向持续演进。
为什么是 Inweave · 设计主旨 · 数据建模 · Shape 平权 · 企业级工作流 · 可演进性 · 快速开始
Inweave 面向正在建设、或计划建设企业内部低代码平台的技术团队，是以 业务数据建模 为核心的企业低代码开源底座，建立在 Nop Platform / Entropy 的可逆计算架构之上。
它既提供工作表、视图、权限、工作流等产品能力，也开放模型与运行时的扩展路径。团队可以从已有能力开始交付应用，再将自己的业务积累沉淀为平台能力，而不必从零搭建所有基础模块。
企业自建低代码平台，需要面对的不只是页面搭建效率。随着业务深入，平台还要回答一组更长期的问题：
- 数据库、表单、接口和权限如何共同使用业务定义，避免各自维护一套字段含义？
- 工作表、视图和流程表单如何保留各自的行为，又不分别建设查询、编辑和关联逻辑？
- 业务关系和规则应该表达在哪里，才能跨应用使用，而不是散落在页面脚本里？
- 接入自研前端、增加企业定制之后，业务内核和基础平台能否继续演进？
Inweave 选择以业务数据模型组织应用：对象与关系描述业务基础，场景模型表达不同入口的要求，运行时执行模型定义的行为。这条路线关心的，不只是交付了多少页面，还有业务增长时能留下多少可复用的能力。
对于计划建设平台的团队，Inweave 提供工作表、视图、权限、工作流等可直接使用的产品能力；对于已经在建设平台的团队，模型、运行时与适配边界提供了继续扩展的实现基础。团队可以从内部应用起步，再把共性业务和领域经验沉淀为多个应用共享的平台能力。
基于元、溶于元、开放源。 这里的“元”，指描述业务结构与行为的元数据及模型体系。这三个主旨贯穿建模、执行和平台演进的设计。
业务从模型出发。对象、字段、关系与规则集中表达，工作表、视图、权限和流程在同一模型体系中组织各自的业务要求，模型定义直接参与实际执行。
岗位、入口和企业定制带来的差异，以 Delta 差量表达，再与基础模型组合为可执行的定义。共性留在基础模型中，企业经验可以继续沉淀到元模型和元编程规则中。
源码、模型和扩展路径向企业开放。团队可以定制应用，也可以扩展元模型、生成规则和运行能力，决定自己的前端和研发方向。
数据建模决定了平台能够表达什么样的业务。Inweave 将对象结构、字段语义、关系和规则纳入模型，使它们成为多个应用入口共同使用的业务定义，而非某个页面的私有配置。
一个模型定义可以组织多个业务对象。对象同时描述业务名称、物理表、稳定标识和展示信息，并通过数据连接确定存储位置。数据连接独立管理数据库配置，区分开发与生产环境，使连接信息与业务对象映射各有归属。
字段不仅具有数据库类型，还可以声明必填、默认值、可新增与可修改属性。数据域用于复用类型、长度和精度等定义，字段也可以覆盖相应的精度设置。
这些语义会转换为动态 ORM 与元数据，字段稳定标识随转换保留，为后续绑定和授权提供身份依据。建模结果由此持续参与数据读写，不止用于生成一次表结构或接口代码。
实体关系支持一对一、多对一、一对多和多对多，描述关联字段、写入方式和中间对象。关系与字段一样具有模型身份，其定义可以向查询、关联选择、详情与表单操作传递，避免每个控件各自解释一次业务联系。
并非所有业务联系都适合表达为物理外键。逻辑关系通过目标对象、查询方式与筛选条件描述关联读取，使跨对象查询可以成为模型中可复用的定义。
实体关系参与 ORM 关系映射，逻辑关系参与关联读取与查询。两者分别保留明确的存储、查询和写入语义，使相似的关联交互背后仍有清晰的业务约束。
对象与字段进入 ORM 和元数据，关系与规则继续参与查询和业务动作，再由工作表、视图和流程表单形成具体入口。一次建模的意义，是让数据库访问、后端行为与应用交互能够沿用同一份业务定义。
flowchart LR
A["业务定义<br/>对象 · 字段 · 关系 · 规则"]
B["模型转换与组合<br/>ORM · 元数据 · 业务动作"]
C["应用入口<br/>工作表 · 视图 · 流程表单"]
D["业务执行<br/>查询 · 编辑 · 关联访问"]
A --> B --> C --> D
这里连接的不只是技术产物：同一个字段的含义和约束、同一个关联的目标，不必在每个入口中重新约定。不同入口需要保留的差异，则由各自的场景模型表达。
同一组业务对象可以服务不同的使用场景。工作表、视图和流程表单需要不同字段、关系目标和动作范围，也需要拥有各自明确的执行身份。
工作表、视图和流程表单的配置生成相应的模型资源，通过 Delta 差量与模型组合复用基础定义、表达入口差异，经校验形成各自的 Shape Model，即当前业务入口实际执行的完整业务模型。每个 Shape 都有自己的身份，声明所需的字段、关系、动作与授权要求，由 ShapeRuntime 执行。
“平权”指模型的执行地位平等，各自的访问权限由对应的授权要求与当前用户共同确定。视图和流程表单与工作表一样，以自己的模型进入 ShapeRuntime，独立承接业务执行。
flowchart TB
B["业务对象与关系"] --> C["Delta 差量与模型组合"]
D["工作表 · 视图 · 流程表单的配置差异"] --> C
C --> W["工作表 Shape"]
C --> V["视图 Shape"]
C --> F["流程表单 Shape"]
W --> R["ShapeRuntime"]
V --> R
F --> R
R --> E["按当前模型执行查询与写入<br/>接入关联能力与授权检查"]
这种平权体现在几个明确的边界上：
- 身份独立。 每个 Shape 都有自己的业务对象身份和完整执行定义，能够承接该入口的查询、写入与动作。
- 模型阶段确定结构差异。 字段裁剪、关系目标、动作范围和授权要求在组合与校验后形成明确的模型事实。
- 运行时执行当前模型。 ShapeRuntime 不回到父工作表临时补字段、补关系或补授权要求，也不按入口来源维护三套业务逻辑。
- 协议在入口层适配。 工作表、视图和流程任务等定位信息先由相应入口处理，运行时接收的是明确的 Shape 执行目标。
Shape 声明授权要求，授权服务在请求时判断当前用户能否执行操作。
这使“溶于元”具有具体的实现含义：新增入口时，通过模型生成与差量组合表达其字段、关系和动作要求，查询、写入和关联所需的通用执行能力可以继续复用。
Inweave 以明道云成熟的企业级工作流为产品参照，复刻其核心使用体系，并将这些能力重新组织到自己的模型驱动架构中。流程定义、用户任务、办理动作、流程表单和业务对象由同一套模型体系组织，申请、审批、办理和协作都围绕真实业务数据展开。
工作流架构将流程设计、发布与运行分别组织，并通过模型化的流程表单和动作连接业务数据。底层引擎负责流程实例的推进，上层模型负责表达企业关心的业务规则、办理上下文、表单结构和数据关联。流程能力可以随着业务模型一起扩展，也可以通过 Delta 承接不同组织和客户的流程差异。
这条路线为企业建设自己的流程平台保留扩展空间：可以复用已有流程能力，也可以继续扩展节点类型、表单结构、动作规则和领域模型，让流程经验沉淀为平台能力。当前 Inweave 已经形成较完整的企业工作流基础，部分高级流程场景仍在持续完善。
模型的执行地位解决了入口如何成立，应用协作还需要回答：不同角色怎样使用这些入口，数据访问和办理过程如何衔接。
工作表承接日常录入、查询与编辑，视图围绕岗位或业务场景组织字段、筛选与操作范围。关联选择、关联详情和子列表继续使用模型中的对象与关系，使应用能够从单表操作扩展为多对象协作。
两种入口可以服务同一批业务数据，又各自拥有不同的字段和行为。视图的筛选条件表达场景需求，数据授权确定当前用户可访问的记录范围，查询同时遵守两者的约束。
对象、字段、记录范围、动作和关联访问所需的授权要求进入执行链。关联查询与动作调用也需要遵守相应的访问边界，而不是仅在主表页面隐藏几个字段或按钮。
前端可见、可编辑提示服务于交互，后端授权负责实际访问控制。将二者围绕同一业务身份组织，是为了减少“界面允许、接口拒绝”或绕过界面后失去约束的语义分歧。
仓库包含车辆、用车申请、油卡充值、加油记录、维保、年检、保险与车队等示例表结构和应用模型输入。它们提供了一组超出单表 CRUD 的业务关系，可作为验证建模、关联与应用协作的起点。
围绕这组业务，不同入口可以承担不同职责：员工关注申请字段与提交动作，审批人围绕当前任务办理，管理员联查车辆与维保、年检、保险记录，财务围绕油卡和费用工作。这些是同一组对象的不同使用方式，不需要因此分别建设车辆主数据。
示例输入位于 init/sql/vehicle_management.sql 和 init/sql/mlc_application.sql。
Inweave 所说的“可演进”，是为不同变化提供明确的扩展位置：业务结构通过模型定义，场景与企业差异通过差量表达，通用能力通过平台实现扩展。
Inweave 继承 Nop 的 XLang、XDef 与 Delta 机制，支持模型生成、结构约束与差量组合。Delta 表达相对于基础定义的新增、修改与删除，模型组合将基础定义与这些差量合并为可执行的模型。团队通过稳定的模型坐标定位修改，让基础模型、场景差异与企业定制可以分层维护。
这种分离使基础能力与企业差异保持可辨认，便于比较变更和验证升级。超出既有表达范围的共性需求，则可以通过扩展模型定义、编译环节或通用服务实现，再供多个应用使用。
模型按租户生成和刷新运行时资源，发布过程区分模型输入、待发布资源与当前可见资源。对象模型、工作表与视图、流程表单通过相应的构建与发布边界进入运行环境，模型变更与受影响资源之间因而有了可定位的关系。
当前产品对接明道云开源前端协议。企业可以沿用现有交互方式，也可以在适配层处理自己的请求、响应与展示差异，后端继续使用明确的 Shape 模型执行。
这种分离让更换前端不必默认成为业务数据模型的重写工程。源码开放使团队能够掌握这些边界，并按自己的需求扩展它们。
页面与数据源连接的路线，通常把业务组织在页面绑定、查询和脚本中；当入口增加时，共享关系和规则需要额外整理。Inweave 以独立的对象、字段和关系模型作为多个入口的业务基础。
数据表与协作的路线适合快速建立表和视图，但业务走向多对象协作后，权限、关联和流程需要重新衔接。Inweave 让这些语义进入模型与 Shape 的实际执行。
静态代码生成的路线把模型转换为一次性的代码产物。Inweave 让模型持续参与查询、写入和业务动作，并以 Delta 组织企业定制，使基础产品和定制可以分别演进。
Inweave 的侧重点，是把数据建模、Shape 平权执行、企业级工作流与可逆计算支持的差量定制结合起来，服务于企业自有平台的长期建设。
Inweave 更适合以下团队：
- 正在建设企业内部低代码、无代码或协同应用平台；
- 希望私有化部署，并掌握数据、模型和演进节奏；
- 不满足于页面搭建，需要承载权限、关系、流程等复杂业务语义；
- 已有研发团队，希望在开源底座上进行长期二次开发；
- 关心五年后的平台可维护性，而不只是第一个应用的交付速度。
详见 init 目录下的文档和脚本。
Inweave 使用 Apache License 2.0 开源，版权归属见 COPYRIGHT.md。
- Nop Platform / Entropy：提供可逆计算、模型驱动与运行时基础能力。
- 明道云开源前端：提供当前产品体验所采用的开源前端基础。
从一个能用的产品开始，长成企业自己的低代码平台。