software-solution-architecture

软件解决方案架构

当问题源自业务工作流、运营模式、系统全景或迁移问题，而非单个服务或可部署边界时，请使用此技能。

此技能会优先确定解决方案的整体形态。在业务流程、参与的系统和迁移形态明确之前，不会默认选择模块化单体与微服务、CQRS、服务网格或 MCP/A2A 等运行时模式。

确定解决方案形态后，如果接下来的问题涉及服务拆分、分布式一致性、平台工程或运行时拓扑，请使用 ../software-architecture-design/SKILL.md。

快速参考

需求	默认做法	接下来阅读
设计涵盖多个系统的目标解决方案	在选择模式之前，先将业务流程映射到系统、职责和约束	references/solution-workflow.md
比较集成方式和边界	根据决策矩阵选择 API、事件、批处理、文件、webhook、BFF 或防腐边界	references/integration-and-boundary-patterns.md
映射能力、负责人和事实来源系统	记录业务能力、负责团队、边界类型和事实来源决策	assets/planning/capability-boundary-map.md
规划分阶段迁移	定义当前、中间和目标状态，以及共存、切换和回滚规则	references/transition-architecture.md
将交付拆分为安全的批次	记录迁移批次的准入、回滚和退役标准	assets/planning/transition-wave-planner.md
整理最终建议	总结目标状态、选项、迁移、风险和交接事项	assets/planning/solution-blueprint.md

不适用场景

• 深入设计运行时或分布式系统 → ../software-architecture-design/SKILL.md
• 实现单个服务 → ../software-backend/SKILL.md
• 深入设计 API 契约 → ../dev-api-design/SKILL.md
• 主要问题是基础设施／平台运维 → ../ops-devops-platform/SKILL.md
• 主要问题是安全架构 → ../software-security-appsec/SKILL.md

边界规则

• 此技能负责系统全景、方案比较和迁移形态。
• 此技能应说明哪些内容保持不变、哪些内容现在变更，以及哪些内容有意推迟处理。
• 此技能不应深入决定可部署单元的数量、内部服务拓扑，或所选解决方案内部的深层一致性机制。
• 如果主要问题转为运行时边界、限界上下文、弹性机制内部设计或平台默认配置，请交接给 ../software-architecture-design/SKILL.md。
• 迁移边界：此技能负责跨系统的迁移批次计划——哪些系统共存、按什么顺序迁移，以及相应的回滚和退役标准。此技能不负责在单个系统内提取或拆分的具体机制（绞杀者模式步骤、数据库拆分、影子流量）——目标架构和拆分方案由 ../software-architecture-design/SKILL.md 的 migration-modernization-guide.md 和 estate-modernization.md 负责；执行机制（一致性验证器、接缝、逐步发布）由 ../qa-refactoring/SKILL.md 的 strangler-fig-migration.md 和 cross-language-rewrite.md 负责。

默认工作流

1. 定义业务场景、参与者和成功指标。
2. 梳理当前系统、所有权边界和关键痛点。
3. 将业务能力映射到系统所有者和权威数据源。
4. 记录硬性约束：合规性、延迟、数据驻留、遗留依赖、供应商限制和发布限制。
5. 在系统版图层面提出 2-3 个可行的解决方案选项。
6. 选择目标状态；如有需要，再选择最小可行的过渡状态。
7. 定义系统职责、集成方式、数据流动、信任边界和验证检查点。使用 集成决策矩阵 选择边界模式。
8. 制定迁移阶段顺序，明确回滚点、共存规则和退役标准。
9. 将更深入的细分工作交给配套技能，涵盖软件架构、API、安全或平台运维。

必需的输出格式

每项建议都应包含：

• 问题陈述和系统范围
• 明确的范围内边界和有意排除在范围之外的边界
• 能力、所有权和权威数据源概要
• 当前状态和目标状态概要
• 分阶段变更时的过渡状态概要
• 推荐选项及被否决的替代方案，并根据可衡量的 NFR 场景评分，列出各选项的成本（构建、运行、迁移、退出）——参见 references/option-scoring.md
• 集成和数据流形态
• 迁移阶段计划，以及适用时的回滚或退出标准
• 主要风险、故障模式和验证检查点
• 暂不应做出的决策
• 明确交接给配套技能的事项
• 每项方案决策对应的 ADR（或 ADR 就绪概要）：背景、决策、状态、后果——以便日后追溯被否决的替代方案，而不只是最终胜出的方案

自建、采购还是合作

信号	倾向于	原因	注意事项
能力没有差异化，且成熟供应商能够提供（例如 KYC、支付处理、电子邮件发送）	采购	更快实现价值；供应商负责运营所采购的能力	数据导出方面的供应商锁定、惩罚增长的定价层级；集成和合规职责仍由你承担
该能力是企业竞争的核心差异化因素	自建	采购核心差异化能力，意味着竞争对手也能购买同样的东西	因沉没成本偏差而自建实际属于通用商品的能力
该能力需要与专有内部数据或工作流进行深入且持续的集成	自建或深度定制	现成工具很少能很好地适配独特的内部流程	“采购”报价单看起来单独很便宜时，低估集成成本
没有内部团队能够长期负责自建解决方案的运营	采购或合作	无人负责的定制系统，比有支持的供应商产品更快退化	因一次性预算周期而选择“自建”，忽略运行成本的归属
监管或合同条款要求指定且经过审计的第三方	合作（受监管供应商）	某些义务无法通过内部自建来满足	误以为供应商认证涵盖整个集成界面，而不只是供应商自身的边界

在根据组织的实际约束（数据驻留、身份验证模型、支持 SLA、退出／导出条款）核实供应商的能力声明之前，应将其视为未经验证——数据手册上列出的能力，并不等同于适合此系统版图所有权和合规边界的能力。

模式选择之外的架构版图选择

• 集成骨干：完全互连的点对点架构版图可能包含平方级数量的连接；实际集成成本取决于所需的连接和契约。iPaaS 或事件骨干可以减少重复的集成工作，但会增加一项共享依赖，并需要指定治理负责人。应根据所需的连通性以及由谁负责跨系统变更来选择。
• 架构版图中的 Agent 和大模型参与方：明确哪些系统提供可由 Agent 调用的接口（例如 MCP），以及 Agent 发起写入时的信任边界在哪里。不得允许 Agent 修改记录系统，除非经过与其他写入方相同的权威数据关卡。运行时层面的 Agent 和工具网关设计应参阅 ../software-architecture-design/SKILL.md。

团队拓扑与康威定律检查

康威定律指出，系统架构版图会映射组织的沟通结构，无论这种映射是否出于刻意设计。在敲定目标状态之前：

• 明确每个业务记录系统和每个集成边界由哪个团队负责；没有明确负责团队的边界会逐渐形成临时且未记录的耦合。
• 检查提议的目标状态是否要求尚不存在的团队结构（例如共享平台团队或新的领域团队）。如果是，转型计划必须将组织设计变更列为明确的依赖项，而不是默认假设。
• 优先选择与可能的团队边界相符的目标状态，而不是架构上优雅、却要求每次变更都跨团队协调的目标状态——协调成本是真实成本，不是可忽略不计的误差。
• 如果目标状态刻意违背当前团队结构（即通过“逆向康威策略”推动期望的架构），应明确说明，并指出由谁负责推动组织变更；不要让这成为图示中未明确说明的副作用。

验证清单

权威数据关卡。

对于跨系统流转的每个业务实体，明确权威归属和收敛规则：单一写入方、按分区划分的写入方，或有意采用多写入方语义。记录允许的副本、传播和因果顺序规则、确定性的冲突处理或合并行为、故障处理方式以及负责协调核对的团队。拒绝允许系统在没有这些语义约定的情况下独立修改同一事实的设计。将临时双写的责任归属纳入转型计划，并定义退役该机制所需的证据。

在敲定解决方案建议之前：

• 以非技术术语定义业务问题和成功衡量标准
• 明确说明每个参与系统的负责人及其记录系统角色
• 记录硬性约束：合规、延迟、数据驻留、供应商限制、发布限制
• 对比 2-3 个解决方案选项，并明确说明拒绝其他方案的理由
• 根据决策矩阵选择集成方式，而非默认所有场景都采用 API
• 如果变更分阶段进行，则定义中间状态（不能只有当前状态和目标状态）
• 为迁移波次制定回滚标准、退出条件和退役计划
• 明确说明哪些事项暂不应做决定
• 明确列出与配套技能（架构、API、安全、平台）的交接事项
• 每项方案决策都有 ADR 或可直接整理为 ADR 的摘要（背景、决策、状态、后果）
• 对任何考虑通过供应商或平台采购获得的能力，说明自建/采购/合作的决策依据
• 根据实际团队归属检查目标状态是否符合康威定律；如果目标状态要求尚不存在的团队，则明确列出组织设计依赖项

已知陷阱

• 尚未明确所有权和事实记录系统的边界，就从业务痛点直接跳到微服务、事件总线或平台采购。
• 描绘整洁的目标状态，却忽略组织实际必须经历的过渡期共存、契约重复或回滚限制。
• 将集成视为对称关系，而实际一方可能拥有权威性、受到速率限制、受法律约束，或在政治层面难以变更。
• 让未来状态图掩盖当前的运营痛点，例如手动变通方案、支持负担或数据对账负担。
• 选择一个横跨过多团队、过多系统，或涉及过多不可逆数据迁移的过渡波次。
• 未验证团队所有权和运营模式，就把企业工具的功能误当成必然能够采用、受到治理或适配运行时的保证。
• 对业务真正的差异化能力建议“购买”，或对成熟供应商已经能够解决的通用能力建议“自建”，却未明确说明取舍。
• 设计优雅的目标状态图，却暗中要求组织具备其并不拥有的团队结构，也未指出这一组织设计依赖。

在将托管迁移或重构服务纳入某个方案前，请查阅提供商文档，确认服务可用性、区域支持、迁移范围和退出行为。应将持久适用的模式（绞杀者模式、ACL、扩展/收缩）与用于实施该模式的产品分别说明。

常见反模式

• 给出看似方案建议、实则暗中偏好某种运行时架构的方案。
• 将每个边界都当成 API 问题，而批处理、文件、事件或防腐层模式可能更适合当前环境。
• 将信任边界、数据管护责任和真实来源冲突含糊地一概归为实现细节。
• 编写迁移计划时只列出起始和结束状态，没有明确的过渡期控制措施、退出标准或退役计划。
• 不顾替换成本可能超过统一带来的业务价值，强行要求所有场景都使用同一平台。

导航

参考资料

• references/solution-workflow.md — 以业务流程为先的方案设计工作流
• references/integration-and-boundary-patterns.md — API、事件、文件、批处理、Webhook、BFF 和 ACL 边界的决策矩阵
• references/transition-architecture.md — 包含波次控制的当前、过渡和目标状态规划
• references/option-scoring.md — 非功能需求场景、跨系统可用性/延迟预算、各方案的成本框架、供应商尽职调查和退出规划
• references/cybernetics-vsm-applied.md — 将 VSM、阿什比定律、反馈回路和警示通道应用于方案架构与系统生存能力。

模板

• assets/planning/solution-blueprint.md — 最终建议方案蓝图
• assets/planning/capability-boundary-map.md — 能力、所有权和事实记录系统工作表
• assets/planning/transition-wave-planner.md — 包含回滚和退役标准的迁移波次规划器

验证

• evals/evals.json — 此技能的触发、不触发和临界行为检查

相关技能

• ../software-architecture-design/SKILL.md
• ../software-backend/SKILL.md
• ../dev-api-design/SKILL.md
• ../software-security-appsec/SKILL.md
• ../ops-devops-platform/SKILL.md

主要来源位于 data/sources.json。

经验循环

如果之前的决策或注意事项与当前任务相关，请查阅 learnings.consolidated.md（如果存在）；仅在需要查看历史记录或没有其他文件可用时，才查阅 learnings.md。否则，请跳过这两个文件。

应用相关经验后，如果你遇到了值得记住的模式、值得避免的错误，或令人意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 向 learnings.md 追加一条带日期的条目。不要修改 SKILL.md 本身。