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