# 架构设计文档正反例

正例展示设计必须达到的可实施粒度；模块、路径、依赖和指标必须来自当前项目事实与已确认决策。

## 正例

### 订单提交边界

- `OrderApplicationService` 只编排库存预占和订单持久化，不包含 HTTP 或 SQL 细节
- `InventoryPort` 由库存适配器实现；订单模块只依赖端口
- 失败路径：库存预占失败不写订单；写订单失败释放预占并记录补偿事件
- 数据流：HTTP DTO → 应用命令 → 领域校验 → 端口 → 持久化适配器
- 观测：按业务错误码统计失败率，补偿事件积压超过 100 条告警
- 回滚：保持旧接口响应兼容，可将流量切回上一实现且不丢失已确认订单

好在：职责边界、依赖方向、失败语义、观测与回滚能直接约束实现和验证。

## 反例

- Controller 接收请求
- Service 处理所有业务
- Repository 操作数据库
- 使用缓存提高性能

问题：没有模块边界、接口、失败路径、数据一致性、指标或决策依据，任何实现都能声称符合。

### 反例触发器形态反例

- ADR 只有结论与理由，没有反例/重审触发器段——决策何时失效无从判定，重审只能靠人想起来。
- 反例触发器写成不可判定的模糊语：「团队成熟后可重审」「业务复杂时再评估」——没有可观测条件与数字，等于没有触发器。

问题：反例触发器的价值在可核验；模糊语既不能触发重审，也不能证明决策仍成立。

## 迁移到当前项目

替换模块、目录、接口、数据流、部署单元、指标和 ADR。每项设计须能追溯到需求、现有系统事实或已确认取舍；不要保留示例架构名和路径。