# ADR 0001: Use A Modular Monolith As The Target Architecture

## Status

Accepted

## Context

当前项目由多个 Python 脚本、目录扫描逻辑、flag 文件和外部命令拼接而成。

主要问题：

- 状态不统一
- 配置不统一
- 重复逻辑多
- 扩展新功能需要继续增加脚本
- 运维和业务边界不清晰

重构目标要求：

- 可扩展
- 可配置
- 可观测
- 易部署
- 易文档化

## Decision

新系统采用模块化单体架构，而不是：

- 继续维护脚本集合
- 直接拆成微服务

## Rationale

选择模块化单体的原因：

- 当前系统规模和团队协作模式不需要微服务
- 单机部署和本地运维是核心需求
- 统一数据库、配置和日志对当前问题最直接有效
- 模块化单体足以提供清晰边界和未来插件扩展能力

## Consequences

正面影响：

- 部署简单
- 重构成本可控
- 便于引入统一状态机和管理 API
- 后续可以逐步插件化

负面影响：

- 需要严格维持模块边界，避免重新长成“大脚本”
- 单进程内错误隔离不如微服务天然

## Follow-Up Decisions

后续还需要补充的 ADR：

- 是否使用 SQLite 作为主状态存储
- 是否引入事件总线
- 插件机制如何注册
- 管理台采用什么技术栈