arch-identify

一句话概述

诊断哪种架构风格或横切模式适合给定问题；如果架构层面的解答过于复杂，则转向更简单的 DDD／设计模式技能。

何时使用此技能

• 全新系统，需要选择宏观架构风格（单体／微服务／事件驱动／无服务器）。
• 现有系统面临可扩展性、集成或事务一致性方面的压力，并询问“哪种模式合适”。
• 架构评审场景：“我们是否应该用 X 而不是 Y？”

何时不使用此技能

• 领域建模问题 → 转向 ddd-design。
• 代码层面的模式问题 → 转向 gof-identify。
• Kotlin 特定的模式问题 → 转向 kp-identify。

核心内容

按以下顺序，通过这些诊断问题分析问题：

1. 这是关于系统的宏观结构吗？

• 默认起点、部署简单、单一代码库 → arch-layered，并采用单体架构。在单体架构出现实际的分界点之前，不要急于采用微服务。
• 将领域核心与框架／数据库／IO 解耦，使它们各自能够独立变化 → arch-hexagonal（端口与适配器）。
• 松耦合组件通过事件异步通信 → arch-event-driven。
• 可独立部署的单元，各自拥有自己的数据，并通过网络通信 → arch-microservices，但请先阅读该技能的“何时不使用”部分；这种风格最容易被滥用。

2. 这是关于跨服务／聚合的数据、事务或一致性吗？

• 读负载与写负载差异很大；读取需要非规范化视图 → arch-cqrs。
• 事实来源是“发生了什么”，而非“当前状态”；需要完整的审计历史和时态查询 → arch-event-sourcing。它通常与 CQRS 搭配使用，但并非必须。
• 一个多步骤业务事务跨越多个服务，且无法使用分布式事务 → arch-saga。

3. 这是关于服务之间的故障处理吗？

• 下游服务性能下降或发生故障；调用服务必须保护自身并妥善恢复 → arch-circuit-breaker（其中还涵盖隔舱和重试策略）。

4. 这是关于如何演进遗留系统吗？

• 从单体逐步迁移到微服务，无法重写，且必须持续交付 → arch-strangler-fig。通常会结合反腐层使用（参见 ddd-context-mapping）。

5. 这是关于架构质量和治理吗？

• 如何确认架构在代码演进过程中仍保持健康 → arch-fitness-functions。
• 如何记录架构决策，让未来的维护者了解原因 → arch-adr。
• 组件级设计规范（单一职责、依赖方向等） → arch-solid。

6. 以上都不符合？

• 这个问题可能不需要架构层面的解答。最常见的情况是：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 ↔ 微服务 ↔ 事件驱动。