1.3 KiB
1.3 KiB
ADR 0001: Use A Modular Monolith As The Target Architecture
Status
Accepted
Context
当前项目由多个 Python 脚本、目录扫描逻辑、flag 文件和外部命令拼接而成。
主要问题：
- 状态不统一
- 配置不统一
- 重复逻辑多
- 扩展新功能需要继续增加脚本
- 运维和业务边界不清晰
重构目标要求：
- 可扩展
- 可配置
- 可观测
- 易部署
- 易文档化
Decision
新系统采用模块化单体架构，而不是：
- 继续维护脚本集合
- 直接拆成微服务
Rationale
选择模块化单体的原因：
- 当前系统规模和团队协作模式不需要微服务
- 单机部署和本地运维是核心需求
- 统一数据库、配置和日志对当前问题最直接有效
- 模块化单体足以提供清晰边界和未来插件扩展能力
Consequences
正面影响：
- 部署简单
- 重构成本可控
- 便于引入统一状态机和管理 API
- 后续可以逐步插件化
负面影响：
- 需要严格维持模块边界，避免重新长成“大脚本”
- 单进程内错误隔离不如微服务天然
Follow-Up Decisions
后续还需要补充的 ADR：
- 是否使用 SQLite 作为主状态存储
- 是否引入事件总线
- 插件机制如何注册
- 管理台采用什么技术栈