用途
arch-identify 用于诊断某个已陈述的问题适合采用哪种架构风格或横切模式，或在架构级回答过重时，将问题路由到更简单的 DDD 或设计模式技能。
何时使用
- 绿地系统，选择宏观架构风格（单体 / 微服务 / 事件驱动 / 无服务器）。
- 既有系统面临扩展性、集成或事务一致性压力，并询问“什么模式合适”。
- 架构评审框架：“我们是否应该用 X 而不是 Y”。
何时不应使用
- 领域建模问题 → 路由到 ddd-design。
- 代码级模式问题 → 路由到 gof-identify。
- Kotlin 特定模式问题 → 路由到 kp-identify。
核心内容
按以下顺序用这些诊断问题审视问题：
- 这是关于系统的宏观形态吗？
- 默认起点、简单部署、单一代码库 → arch-layered，并保持单体。在单体出现真实接缝之前，不要转向微服务。
- 将领域核心与框架 / 数据库 / IO 解耦，使各自可独立变化 → arch-hexagonal（端口与适配器）。
- 松耦合组件通过事件异步通信 → arch-event-driven。
- 独立可部署单元，各自拥有数据，通过网络通信 → arch-microservices——但先阅读该技能的“when NOT to”部分；它是最被过度应用的风格。
- 这是关于数据、事务或跨服务 / 聚合的一致性吗？
- 读负载与写负载差异很大；读需要非规范化视图 → arch-cqrs。
- 事实来源是“发生了什么”，而不是“当前状态”；完整审计历史；时间查询 → arch-event-sourcing。与 CQRS 天然搭配，但不要求 CQRS。
- 多步业务事务跨越多个服务，没有可用的分布式事务 → arch-saga。
- 这是关于服务之间的故障处理吗？
- 下游服务降级或失败；调用服务必须保护自身并优雅恢复 → arch-circuit-breaker（其中还涵盖舱壁和重试策略）。
- 这是关于演进遗留系统吗？
- 从单体增量迁移到微服务，无法重写，必须持续交付 → arch-strangler-fig。通常与防腐层结合使用（见 ddd-context-mapping）。
- 这是关于架构质量与治理吗？
- 随着代码演进，如何知道架构保持健康 → arch-fitness-functions。
- 如何记录架构决策，以便未来维护者知道原因 → arch-adr。
- 组件级设计纪律（单一职责、依赖方向等）→ arch-solid。
- 以上都不是？ 问题可能不需要架构级回答。最常见的是：DDD 建模决策（ddd-design）、代码级模式（gof-identify），或“不要过度设计——保持单体”。
决策启发式
- 默认先单体，直到有具体理由进行分布式。
- 默认分层，直到有具体理由翻转依赖方向（这正是六边形架构所做的）。
- 分发是成本，不是特性。微服务、saga、事件驱动、CQRS 都会增加运维复杂度。用具体需求来证明它们的必要性。
- “我们这样构建是因为[知名公司]这样做”不是理由。
反模式
- 先选微服务，然后试图改造领域模型——导致数据耦合和话痨服务。
- 因为“听起来高级”而采用 CQRS，却没有实际的读写不对称——纯粹是额外开销。
- 在单个事务边界就足够时却使用 saga——saga 的补偿操作是真实的工程成本。
- “简历驱动开发”——为了职业信号而不是适配性选择架构。
参见
- 全部十三个 arch-* 模式技能。
- ddd-design 和 ddd-bounded-context——DDD 常在选择任何模式之前就影响架构级决策。
- gof-identify——当问题是代码级而非系统级时。
参考资料
- Richards & Ford, Fundamentals of Software Architecture (O'Reilly, 2020) — 第 18 章，Choosing the Appropriate Architecture Style。
- Khononov, Learning Domain-Driven Design (O'Reilly, 2021) — 第 14–15 章，DDD ↔ 微服务 ↔ 事件驱动。