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