用途
BFF Design 用于在架构层面决定是否引入后端为前端（Backend-for-Frontend，BFF）模式，以及如何设计、拆分和治理 BFF。其核心立场是：BFF 首先是一种所有权模式，而非技术。客户端应用使用的 API 是该应用的一部分，由拥有前端的团队拥有，且不被其他应用消费。从架构上看，BFF 是单一用户体验的驱动宿主，负责塑造、聚合和中介，但不做决策。
该技能负责模式层面的决策：是否要有 BFF、要几个、每个可以拥有什么、如何聚合上游并承受上游失败、如何将用户身份携带到上游服务。BFF 自身边界的保护由 bff-entry-points 负责；物理路由布局由 structure-codebase 负责；对外消费的 API 契约由 api-design 负责；OAuth/OIDC 协议流程由 secure-oauth-oidc 负责。
主要能力
- 采用判断：通过信号表判断是否需要 BFF，例如出现第二种客户端类型、单页扇出到多个下游调用、前端团队排队等待通用 API 团队、浏览器应用处理敏感数据等。若只有一个界面、对单一后端发出简单相似的请求，则明确不适合。
- 粒度与所有权：以“体验”为粒度单位，一个体验一个 BFF；同一体验的 iOS 与 Android 构建属于同一消费者。前端团队拥有其 BFF，BFF 与前端是同一逻辑部署单元。
- 塑造而非决策：BFF 拥有展示模型工作（聚合、重塑、载荷瘦身、按体验默认值、将上游结果翻译为 UI 所需形式），但不拥有业务规则、产品授权和持久领域状态。
- 聚合与韧性：并行扇出、传播每请求截止时间、为每个上游设置经验性超时、每条边只有一个重试所有者、在契约中区分必需与可选响应段、可选段降级而非整页失败、按身份键控缓存。
- 上游身份：向上游转发用户身份而非 BFF 自身服务身份加用户头；使用访问令牌时按上游交换为窄受众、降范围的令牌，或按资源获取令牌；事务令牌模型下则传播信任域范围的签名上下文。
- 公共 API 失败模式：当第二个体验消费 BFF 时它就不再是 BFF；通过分离表面、为新消费者建立自己的表面、监控凭证模式与客户端注册来设置护栏，并给出漂移恢复步骤。
使用方式
在做出决策前阅读相关参考文档：决定是否采用、运行几个 BFF、谁拥有、移动版本偏差、可部署与模块的规模选择时，阅读 references/adoption-and-granularity.md；当 BFF 扇出到上游服务时，阅读 references/aggregation-and-resilience.md；当 BFF 代表用户调用上游服务时，阅读 references/upstream-identity.md；当权衡 BFF 与共享网关、GraphQL 联邦、令牌中介后端、SPA 直连 API 或元框架服务器时，阅读 references/alternatives.md。
适用场景
适用于采用或拆分 BFF、聚合上游服务、处理上游失败、向下游转发用户身份、权衡 GraphQL 与按客户端 BFF，或审计已漂移为公共 API 或业务逻辑层的 BFF。也适用于已经运行 GraphQL 且带前端特定解析器，或使用元框架服务器（Next/Remix/SvelteKit）的情况——此时可能已经拥有 BFF，应直接应用本技能而非再增加一个组件。
限制
资料未提供该技能的具体安装命令、运行环境要求、收费方式或价格信息。该技能为设计决策类技能，不提供可直接执行的代码实现；具体机制与来源需阅读对应参考文档。BFF 自身入口点保护、物理路由布局、外部 API 契约和 OAuth/OIDC 协议流程分别由其他技能负责，本技能不重复。