从零搭建企业后台：我为何将核心能力划分为Starter与Plugin

微内核插件化架构如何破解企业后台系统常见的模块耦合与复用难题？本文将深入剖析其核心设计思路与实现方案。

1. 这个问题在企业后台里为什么常见

企业后台系统在长期迭代中往往会面临三类典型问题：

场景一：半年后，代码已经分不清边界

系统初期模块划分清晰，但随着需求不断叠加，功能代码逐渐失控：

1. 用户模块混杂登录日志和操作日志查询功能
2. 角色模块包含导出用户数据的业务逻辑
3. 文件模块的鉴权逻辑分散在多个控制器
4. 多租户改造导致大量接口添加tenant_id条件

当需要重构时，任何改动都可能引发连锁反应。

场景二：新项目要复用旧项目的「通用能力」

技术组件的复用面临诸多适配问题：

1. 认证模块与特定日志配置强耦合
2. Excel模板依赖特定的实体类结构
3. 数据源切换机制绑定特定注解实现

这些技术债务导致复制代码比重新开发更耗时。

场景三：想「裁剪」掉不需要的能力

系统瘦身时发现：

1. 工作流代码渗透到多个业务模块
2. 消息通知与服务模块深度耦合
3. 模块间存在隐式服务依赖

这些问题的根源在于能力边界模糊，模块耦合严重，缺乏标准化接口。

2. Forge Admin 是怎么解决的

采用微内核+Starter+Plugin三层架构实现能力解耦。

2.1 整体结构

forge-framework/                      # 框架层（不依赖具体业务）
├── forge-dependencies/               # 统一依赖版本管理（BOM）
│
├── forge-starter-parent/             # 【技术 Starter】可插拔技术能力
│   ├── forge-starter-core/           # 核心工具类、异常、统一响应
│   ├── forge-starter-web/            # Web 层封装（Undertow + 全局异常处理）
│   ├── forge-starter-auth/           # 认证授权（Sa-Token + 权限注解）
│   ├── forge-starter-orm/            # ORM（MyBatis-Plus + 动态数据源 + 分页）
│   ├── forge-starter-cache/          # 缓存（Redis + Redisson 分布式锁）
│   ├── forge-starter-tenant/         # 多租户（TenantLineInnerInterceptor）
│   ├── forge-starter-datascope/      # 数据权限（DataScopeInterceptor）
│   ├── forge-starter-crypto/         # API 加解密（@ApiEncrypt / @ApiDecrypt）
│   ├── forge-starter-excel/          # Excel 导入导出（EasyExcel）
│   ├── forge-starter-file/           # 文件存储（OSS / RustFS / 本地）
│   ├── forge-starter-log/            # 操作日志（@OperationLog）
│   ├── forge-starter-idempotent/     # 幂等性（注解 + Redisson 分布式锁）
│   ├── forge-starter-id/             # 分布式 ID（雪花算法）
│   ├── forge-starter-config/         # 动态配置刷新（@RefreshScope）
│   ├── forge-starter-trans/          # 分布式事务
│   ├── forge-starter-social/         # 社交登录
│   ├── forge-starter-websocket/      # WebSocket
│   ├── forge-starter-message/        # 消息服务
│   ├── forge-starter-job/            # 任务调度基础设施
│   └── forge-starter-api-config/     # API 行为动态配置
│
├── forge-plugin-parent/              # 【业务插件】可插拔功能模块
│   ├── forge-plugin-system/          # 系统管理（用户/角色/菜单/部门/岗位/租户/字典）
│   ├── forge-plugin-generator/       # 代码生成器（AI 驱动）
│   ├── forge-plugin-job/             # 定时任务（Quartz / SnailJob）
│   ├── forge-plugin-message/         # 消息中心（站内信/邮件/短信）
│   ├── forge-plugin-flow/            # 流程引擎（Flowable）
│   ├── forge-plugin-ai/              # AI 供应商管理
│   ├── forge-plugin-external/        # 外部扩展
│   └── forge-plugin-data/            # 数据模块
│
forge-admin-server/                   # 【主应用】聚合所需插件，对外提供接口

2.2 核心设计原则

架构类比：

1. Starter是标准化的技术插座
2. Plugin是可插拔的业务电器
3. 主应用是灵活配置的配电箱

2.3 解决了什么问题

3. 核心设计：Starter 与 Plugin 的边界

3.1 Starter：技术能力下沉

专注于封装通用技术实现，提供标准化接口。

典型 Starter 示例：