用途
当问题从业务工作流、运营模式、系统全景或过渡问题出发，而不是从单个服务或可部署边界出发时，使用本技能。本技能首先选择解决方案形态，不会在业务流、参与系统和过渡形态明确之前，默认采用模块化单体与微服务、CQRS、服务网格或 MCP/A2A 等运行时模式。当解决方案形态已知，下一个问题是服务分解、分布式一致性、平台工程或运行时拓扑时，应改用 ../software-architecture-design/SKILL.md。
主要能力
- 将业务流映射到系统、职责与约束，再选择模式。
- 从决策矩阵中选择 API、事件、批处理、文件、Webhook、BFF 或防腐层边界。
- 捕获业务能力、归属团队、边界类型与权威数据源决策。
- 定义当前、过渡与目标状态，包含共存、切换与回滚规则。
- 将交付排序为安全波次，捕获迁移波次进入、回滚与退役标准。
- 打包最终建议，汇总目标状态、选项、过渡、风险与交接。
使用方式
默认工作流：
- 定义业务场景、参与者与成功度量。
- 映射当前系统、归属边界与关键痛点。
- 将业务能力映射到系统所有者与权威数据源。
- 捕获硬约束：合规、延迟、数据驻留、遗留依赖、供应商限制与发布限制。
- 在系统全景层面提出 2-3 个可行方案选项。
- 选择目标状态，必要时选择最小可行过渡状态。
- 定义系统职责、集成风格、数据移动、信任边界与验证检查点。使用集成决策矩阵选择边界风格。
- 排序迁移波次，包含回滚点、共存规则与退役标准。
- 将更深入的切片移交给软件架构、API、安全或平台运维等配套技能。
必需输出形态：每个建议应包含问题陈述与系统范围；明确的范围内与有意排除的边界；能力、归属与权威数据源摘要；当前状态与目标状态摘要；分阶段变更时的过渡状态摘要；推荐选项及被拒绝的替代方案，按可度量 NFR 场景与每选项成本（构建、运行、迁移、退出）评分；集成与数据流形态；相关时的迁移波次计划与回滚或退出标准；主要风险、失败模式与验证检查点；尚不应决定的事项；到配套技能的明确交接；每个选项决策的 ADR 或 ADR 就绪摘要（上下文、决策、状态、后果）。
适用场景
- 跨多个系统设计目标解决方案。
- 比较集成风格与边界。
- 映射能力、所有者与权威数据源。
- 规划分阶段迁移。
- 将交付排序为安全波次。
- 打包最终建议。
限制
不适用：深度运行时或分布式系统设计 → ../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。
构建 vs 购买 vs 合作：能力无差异且成熟供应商覆盖时倾向购买；能力是业务竞争的核心差异化时倾向构建；能力需要与专有内部数据或工作流深度持续集成时倾向构建或重度定制；没有内部团队能长期运营自建方案时倾向购买或合作；监管或合同条款要求具名、经审计的第三方时倾向合作（受监管供应商）。在根据组织实际约束（数据驻留、认证模型、支持 SLA、退出/导出条款）检查之前，将供应商能力声明视为未经验证。
团队拓扑与康威定律检查：在最终确定目标状态之前，命名每个权威数据源与每个集成边界的归属团队；检查提议的目标状态是否需要尚不存在的团队结构；优先选择匹配可能团队边界的目标状态；当目标状态有意违背当前团队结构时，明确说明并命名谁负责推动组织变革。
验证清单：权威数据门——对每个跨系统的业务实体，命名权威归属与收敛规则：单一写入者、分区拥有的写入者或有意的多写入者语义；记录允许的副本、传播与因果排序规则、确定性冲突或合并行为、失败处理与对账所有者；拒绝系统可独立修改同一事实而无这些语义的设计；在过渡计划中包含临时双写归属并定义退役所需证据。最终确定前检查：业务问题与成功度量以非技术术语定义；每个参与系统有明确所有者与权威数据源角色；硬约束已捕获；2-3 个方案选项比较并明确拒绝理由；集成风格从决策矩阵选择；分阶段变更时定义过渡状态；迁移波次有回滚标准、退出条件与退役计划；明确说明尚不应决定的事项；命名到配套技能的交接；每个选项决策有 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 — NFR 场景、跨系统可用性/延迟预算、每选项成本骨架、供应商尽职调查与退出规划；references/cybernetics-vsm-applied.md — VSM、Ashby 定律、反馈循环、algedonic 通道应用于解决方案架构与系统生存性。模板：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 本身。