不是加功能，是清债。
今天把项目底层架构、表规范、分包规范、端职责划分一次性全部闭环定型。
从此，项目从杂乱结构变成标准领域分层架构。
一、背景：为什么要做这次架构规整？
项目前期为了快速上线，表命名不统一、分包随意、职责边界模糊。随着业务复杂度上升，问题越来越明显：
-
表命名混乱 ：
admin_user、article_structured，没有统一前缀 -
分包随意：实体、Mapper、Service 混在一起，职责不清
-
端职责混淆：管理端API和C端API边界模糊，后续扩展困难
-
跨模块依赖不清晰：ConfigService 直连 Mapper，违反分层原则
这不是"加功能"，而是在偿还技术债务。
二、核心规整内容
1. 数据库表名全量规范整改
统一三套业务前缀：
| 前缀 | 业务领域 | 示例 |
|---|---|---|
sys_ |
系统底座 | sys_admin_user |
ai_ |
AI内容中心 | ai_article_structured |
biz_ |
C端业务 | biz_xxx |
整改关键表：
-
admin_user→sys_admin_user -
article_structured→ai_article_structured -
全部 C 端业务表统一加
biz_前缀
库表层命名彻底统一，无混淆。
2. 实体类适配整改
所有修改后的表，同步更新实体类 @TableName 注解。保留 Java 类名简洁不改名，只绑定规范表名，兼顾代码可读性和数据库规范。
3. Framework 二级模块正式拆分落地
拆分为三大领域，分层职责清晰：
| 领域 | 包名 | 职责 |
|---|---|---|
| 系统底座 | system |
用户、角色、菜单、字典、配置 |
| AI内容中心 | ai |
文章、知识库、结构化、仿写 |
| C端业务 | biz |
面向用户的业务逻辑 |
所有实体、Mapper、Service 按领域归位分包。
4. Admin 管理端控制器合理拆分
确定不混进 C 端 biz 命名，新增 console 运营控制台包。
Admin 最终三分结构：
| 包名 | 职责 |
|---|---|
system |
系统管理（用户、角色、菜单、字典） |
ai |
AI内容管理（文章、知识库） |
console |
运营业务管理（C端业务的管理后台） |
彻底和 C 端业务解耦，不混淆。
5. 跨模块配置架构定型
-
ConfigService放在api层做契约 -
ConfigServiceImpl放在framework，依赖SysConfigService，不直连 Mapper
符合分层防腐标准，无循环依赖。
三、最终达成成果
-
✅ 工程分包、模块划分、表名命名、注解绑定------全部企业级规范化
-
✅
system/ai/biz三大领域架构对齐 -
✅ Admin / Customer 端职责边界彻底划清
-
✅ 现有业务代码全部适配新架构，无需重构，可直接正常运行
-
✅ 项目地基彻底打牢，后续只需要按业务迭代开发，再也不用折腾架构和结构
-
✅ 已整理好后续分步落地待办清单，存档可随时按顺序开发
四、整体感受
今天从杂乱结构改成标准领域分层架构。不是加功能，是清债。地基打好了，后续开发再也不会乱包、乱命名、职责混淆。接下来，直接进入业务稳步迭代阶段。
这篇是《产品底稿》系列的第 11 篇，也是架构治理阶段的收官之作。接下来会进入业务模块的稳步迭代，如果你对项目工程化、AI 知识库产品落地感兴趣，欢迎订阅专栏持续跟进，也可以看看我的置顶导航，了解完整的内容体系。