仓库
当然使用github进行管理。但是这次并不是单独一个仓库，而是使用submodules进行管理。也就是说结构变成 一个主仓库关联多个子仓库，其中主仓库存储这子仓库某个版本的id，这样就可以追踪到子仓库快照。
为什么采用这个？
同事用过，俺寻思我也想试试怎么个事儿。
优势
- 可以通过主仓库一次性操作所有关联仓库的版本 （确实舒服，一次性回滚多个仓库）
- 代码方便仓库级别复用（没享受到）
劣势
- CI/CD支持不好 （虽然我也没用）
- 学习成本高（毕竟不少人都没听过）
- 维护复杂度高 （就说一点： 子仓库更新版本，主仓库不更新的话就相当于没更新）
- 协作成本高 （我一个人，没这问题）
# 此时已经clone主仓库了 git status git remote -v # 查看当前仓库信息 git submodule add 子仓库链接 contract-file#子仓库文件夹 git submodule status # 可以看到子仓库分支 cat .gitmodules #也可以看到每个目录对应的子仓库信息以上一同操作下来就是一个子仓库的链接，由于idea的git图形化做的比较好，所以只要关联过后就可以图形化操作了。
设计的模块划分（理想是好的）
我的模块按照功能进行划分。首先讲一下完整的服务应该有哪些，我会标注一下每个模块的完成进度
1. 核心业务模块（7个）
- 合同管理模块- 合同上传、类型识别、附件管理
- 智能审查引擎- 条款提取、任务编排、大模型调用、规则执行
- 规则管理模块- 系统规则库、自定义规则、权重配置
- 提示词管理模块- 模板库、变量处理、效果评分
- 知识库模块- 条款样本、法规判例、企业标准
- 报告生成模块- 结构化输出、PDF/Word导出、版本管理
- 文本对比模块- 差异算法、并排对照、风险定位
2. 支撑服务模块（4个）
- 用户权限模块- 认证授权、审计水印（当前单用户）
- 任务调度模块- 任务队列、流程配置、状态管理
- 历史记录模块- 任务追踪、版本快照、日志记录
- 统计治理模块- 运营数据、成功率监控、基线管理
3. 基础设施模块（3个）
- API网关模块- 错误码、限流、缓存、幂等控制
- 存储模块- 文档存储、元数据、缓存、审计日志
- 外部集成模块- 大模型适配、格式转换、第三方集成
4. MVP实施优先级
P0核心：合同管理、审查引擎、报告生成、文本对比、API网关、存储
P1基础：规则管理、提示词、知识库、任务调度、历史记录、外部集成
P2占位：用户权限、统计治理
模块实际进度
看到这个标题应该也会意识到，个人开发往往不会有设计中的那么美好，尤其还是自己一个人的时候，所以划分出这么多模块的时候我就考虑到会舍弃一些所以划分的优先级，但是实际操作起来放弃的功能和模块要多得多。
废弃的模块：文本对比模块（难度太高，业务没有稳定则不能开发）、用户权限模块（自行开发费时费力，在界面上难以体现）、历史记录模块（过于细分）、统计治理模块（demo版本不开发，除非有需求）
合并的模块：规则管理和提示词管理合并入合同管理模块、报告生成模块和任务调度模块合并入 审查引擎、
暂未开始的模块：知识库模块
实际的模块划分（不能偏离现实）
所以实际的模块有以下几个，并且明天我会详细介绍模块的功能边界和定位。
1. 核心业务模块（2个）
- 合同管理模块 contract-management- 合同上传、类型识别、附件管理
- 智能审查引擎 contract-review-engine- 条款提取、任务编排、大模型调用、规则执行
2. 支撑服务模块（3个）
- 通用依赖模块 contract-common- 多服务通信Feign和相关传输类、通用工具类
- 鉴权模块 contract-security-ruoyi- 远程鉴权、角色管理、权限管理，基于ruoyi-vue springboot3分支开发。
- 错误管理模块 contract-exception-handler- 全局错误捕获、错误日志记录、错误码管理
3. 基础设施模块（3个）
- 网关模块 contract-gateway- 限流、缓存、幂等控制、简单认证
- 存储模块 contract-file- 文档存储、元数据
- AI集成模块 contract-ai- 大模型适配、格式转换、第三方集成
明日会来讲解一下具体模块
