用途：这是一个软件架构模式的决策框架技能，目标是帮助开发者在设计与重构系统时判断“该用哪个模式”，而不是把模式当成记忆清单。核心理念是“模式解决问题；没有问题就不需要模式”。
主要能力：把模式分为两类。基础性模式默认适用，包括依赖注入（解决紧耦合、类自行实例化依赖、代码难测试）与面向服务架构（解决单体纠缠、边界不清、业务逻辑分散）。情境性模式在被特定问题触发时才用，包括仓储模式（服务知晓数据库细节）、领域事件（服务循环调用、时间耦合）、防腐层（外部 API 变化导致代码损坏）、断路器（单个慢服务拖垮整体，可配合重试与退避）。
使用方式：资料给出快速决策树，按顺序自问——代码难测试则用依赖注入；业务逻辑分散则用 SOA；服务知晓数据库细节则用仓储；服务循环调用则用领域事件；外部 API 变化破坏代码则用防腐层；一个慢服务拖垮全局则用断路器；都没有则当前模式足够。新系统建议先建立 DI，再划服务边界，再加仓储，最后按需叠加情境模式；重构时先定位具体痛点，只应用能解决它的最小模式，验证有效后再继续。
适用场景：设计新系统或重大功能、集成外部服务、代码难以测试或修改、服务互相循环调用、单点故障扩散、业务逻辑散落各处。常见组合：新微服务用 DI+SOA+仓储；外部 API 集成用 DI+防腐层+断路器；事件驱动系统用 DI+SOA+领域事件；数据密集型应用再加工作单元。
限制与提醒：文档明确列出红旗信号，如“先把这些模式都加上”“这是最佳实践”“以后可能用得上”“服务定位器更简单”“直接调用服务就行”“外部 API 很稳定不需要防腐层”，遇到这些应先停下来识别具体问题。资料未提供具体语言实现代码、安装命令或价格信息。