应用架构
iBizHUB采用创新的多应用协同架构模式，突破了传统单一应用结构的局限性。该架构特别适合大型企业级应用场景，能够有效支持多团队并行开发、渐进式架构演进和复杂业务系统的长期维护。
从应用架构层级纵向划分，我们认为包含应用基座(AppHub)、应用(App)、视图(View)、视图布局(ViewLayout)、部件(Widget)和部件项(WidgetItem)等核心元素；从数据流横向划分，则遵循UI展示层、UI服务层和数据服务层的三层架构模型，实现界面与逻辑的清晰分离。
核心价值
本架构采用基于基础应用的扩展模式，具有以下核心价值：
模块化扩展能力：通过子系统机制实现功能扩展，保持基础应用稳定性
独立开发部署：子系统开发完全解耦，支持独立技术栈与部署流程
无缝集成：通过平台级挂载机制实现功能聚合，确保系统完整性
非侵入式扩展：功能增强无需修改基础应用代码，降低系统耦合度
设计原则
视图全局唯一性：在多应用环境下确保视图标识全局唯一，作为应用域划分的依据
领域隔离：通过视图入口明确界定应用边界，实现业务领域隔离
动态集成：支持运行时应用挂载，实现真正的热插拔架构
基础设施共享：应用基座提供统一的身份认证、路由管理、状态管理等基础服务
核心元素
| 名称 | 描述 |
|---|---|
| 应用基座(AppHub) | 作为微前端架构的核心容器，提供统一的运行时环境、共享基础设施服务（路由/状态/权限管理）、应用注册与挂载机制，全局模型的获取、缓存、注册，并协调跨应用通信，确保多应用协同运行。 |
| 应用(App) | 独立业务功能单元，具备完整业务闭环，支持独立部署，通过应用模型数据合并与基座集成，实现模块化开发与动态扩展。 |
| 视图(View) | 应用组成的基本单元，定义应用上下文边界，承载路由映射与权限控制，决定界面渲染所属应用域。 |
| 视图布局(ViewLayout) | 界面结构组织方案，支持动态插槽布局，提供一致的框架结构，同时允许通过业务建模工具自定义区域布局与样式。 |
| 部件(Widget) | 高复用业务组件，遵循标准化模型接口规范，支持跨应用共享与上下文感知，提供可视化配置能力。 |
| 部件项(WidgetItem) | 原子级UI单元，作为部件的最小功能元素，分为纯展示型与交互型，强制实现无障碍访问与标准化数据输入/输出接口。 |
针对核心元素这块内容，我们以一个ERP应用（包含采购应用、库存应用等多个应用）作为例子，展示我们对于应用的设计思路。
- 应用基座(AppHub)
作为ERP应用的核心容器，应用基座负责承载和管理所有子应用的运行时环境。它以主应用的身份提供统一管理能力，包括应用注册、路由调度、状态共享等核心能力。确保采购、库存等模块既能独立开发部署，又能无缝集成。基座还提供统一的身份认证、权限控制和基础服务，为上层应用提供一致的运行底座。
- 应用(App)
每个功能模块（如采购、库存）被设计为独立的应用单元，具备完整的业务闭环能力。以采购应用为例，它封装了采购订单管理、供应商协同等业务逻辑。应用层设计强调高内聚低耦合，支持按需加载和动态卸载，确保系统具备良好的可扩展性和可维护性。
- 视图(View)
视图代表应用内的具体功能页面，是用户交互的核心载体。采购应用的采购清单和详情页作为独立视图，各自维护专属的路由状态和UI逻辑。每个视图可独立配置权限策略，同时通过基座提供的跨视图通信机制实现数据联动，例如清单页选择条目后自动跳转至详情页。
- 视图布局(ViewLayout)
视图布局定义页面的整体视觉框架和区域划分。采购清单页采用"顶部工具栏+中部搜索区+底部表格"的三段式布局，而详情页使用"标题区+卡片式表单"的紧凑布局。布局与视图解耦设计，使得同一业务视图可快速切换多套布局方案，满足不同场景下的展示需求。
- 部件(Widget)
作为视图的原子功能单元，部件是具有独立功能的UI组件。采购清单页的工具栏（包含新建/导出按钮）、搜索表单（筛选条件组合）和表格（分页数据展示）分别实现标准化Widget接口。每个部件自主管理内部状态，通过事件的方式与其它部件通信。系统提供Widget仓库支持全局复用，例如不同业务模块可共享同一套高级表格组件。
- 部件项(WidgetItem)
部件项是Widget内部的细粒度UI元素，构成完整的交互链路。以搜索表单为例，其数据录入区（包含供应商选择器、日期范围等表单项）和操作区（查询/重置按钮组）作为独立WidgetItem存在。表单项进一步拆分为表单分组、表单项、编辑器等元素，通过配置化声明实现动态渲染。
针对上述ERP应用的例子，大致思路如下：
数据流
在从界面渲染到接口交互的完整链路中，我们采用UI展示层、UI服务层和数据服务层的三层架构模型，实现界面与逻辑的清晰分离。
UI展示层负责界面渲染、用户交互及事件处理，由UI组件和UI控制器构成，两者通过数据绑定或事件机制通信，而UI控制器则与UI服务层交互，确保UI与业务逻辑解耦。
UI服务层作为业务逻辑的中间层，封装前端通用场景能力，如数据字典管理、界面计数统计、权限控制和交互逻辑处理，向下调用数据服务层获取数据，向上为UI展示层提供标准化的业务接口。
数据服务层专注于数据管理，包括远程API请求、本地缓存策略及数据格式转换，为上层提供统一的数据访问接口，保障数据的高效存取和一致性。
该架构遵循分层解耦原则，严格限制单向依赖（UI展示层→UI服务层→数据服务层），避免逆向调用破坏层级边界。各层职责高度内聚，展示层仅关注UI呈现，服务层处理业务规则，数据层管理数据源，确保逻辑隔离。交互方式通过标准化契约（如事件、DTO）定义，提升代码可维护性和可测试性，同时支持动态替换底层实现（如Mock数据或不同API版本）。
图示进一步明确分层关系：用户操作触发UI组件事件，由UI控制器协调UI服务层执行业务逻辑，服务层通过数据服务层获取或更新数据后，逐层返回处理结果并更新界面。数据流严格遵循层级约束，形成可预测的闭环链路。