BFF 做接口编排时不要越过的边界

BFF 最容易让团队上手的价值，是它能把前端要的多个接口结果拼成一个更顺手的响应。但编排一旦做顺了，也特别容易越界。

最典型的信号就是: 一开始只是“聚合几个接口”，后来逐渐开始承担复杂业务判断、数据修补、权限分流，甚至偷偷长成一个第二后端。

BFF 最适合做的是视图导向编排

比如一个首页卡片要同时拿用户摘要、待办数量和推荐内容，这种典型的多接口编排就很适合放在 BFF。因为它本来就是为某个页面形态服务的。

换句话说，BFF 的组织方式应该更多围绕页面或前端场景，而不是围绕领域模型本身。

真正的业务规则还是要留在下游服务

如果文章是否能发布、订单是否能退款、用户是否命中风控这些规则都开始写进 BFF，后面很快会出现两个问题:

• 规则被复制到多个入口
• 前端专用接口反过来绑架核心业务

所以我更认可的边界是，BFF 负责“怎么组合结果”，下游服务负责“这件事到底能不能做”。

BFF 可以改形状，但别偷改语义

聚合层非常适合做字段裁剪、重命名、补默认值、把多条请求结果拼成一个对象。这些都属于响应形态重组。

但如果 BFF 开始替下游服务“修正业务结果”，比如把失败悄悄当成功处理、或者把某个状态重新解释，那前后端都会越来越难定位问题。

编排深度要控制

我比较警惕那种一层 BFF 去串四五个下游，再让其中某个下游继续调别的服务的链路。因为一旦链路太深，超时、重试和熔断的复杂度会迅速上升。

2021 年做中型系统时，我更倾向于让一个 BFF 接口只承载一个明确页面场景，并把依赖数控制在能读懂的范围里。

小结

BFF 真正的价值是降低前端调用复杂度，而不是变成新的业务中枢。只要把“视图编排”和“业务决策”这条线划清，聚合层就会长期好维护得多。