如何在中后台领域玩转BFF架构

如何在中后台领域玩转 BFF 架构

摘要

我们的供应链场景有很多供应商，每个供应商都有物流、资产、仓储等多个域，而这些域我们的后端都基于 DDD 领域模型做了微服务化，此时前端在开发面向这些供应商使用的中后台应用时，遇到了以下问题：

页面显示需要请求多个域：比如一个商家的详情页，可能既需要请求仓储数据，还需要请求资产数据，才能将一个页面显示出来。

接口格式不满足前端需求：后端微服务化后，是面向多项目，通用性的，其接口格式不一定能满足前端需求，前端需要自己做转换，比如单位转换，字段裁减。

需求变化快：业务在快速迭代，需要接口的大量支持，而我们的后端域是面向多项目的，更改成本较大，需要投入更多的测试，此时如果在前端和后端中间存在一个中间层，来做这些事情，那么效率会有比较好的提高。

部门协作成本大：有些需求需要其它部门的后端同学支持，而其它部门的同学因为自己部门的需求紧张，排期较满，导致我们的需求迟迟无法排期，此时如果存在一个中间层，在中间层去请求其它部门提供的领域服务来组合数据提供给前端，此时就可以在其它部门同学不参与的情况下，前端自己完成需求开发，部门之间的协作成本会大大降低。

基于以上背景，前端这边引入了 BFF 架构，BFF 架构能做哪些事情：

业务编排：从后端域多接口获取数据合并输出给页面。比如一个商家详情页即需要仓储数据，也需要资产数据，此时我们在 BFF 层将仓储和资产数据请求回来组装吐给前端。

字段转换：字段过滤、数据格式化等工作。比如资产域的商户名字段叫 businessName，而仓储域的商户名字段叫 shopName，此时可以在BFF层统一掉，这样前端就不需要做判断了。

个性化数据：为前端提供个性化服务，如数据压缩，单位转换等。