机翻微调，分享信息，不喜勿喷，欢迎建议。
创建单独的后端服务，以供特定的前端应用程序或接口使用。当你想要要避免为多个接口定制单个后端时，此模式很适用。这种模式最早由山姆·纽曼（Sam Newman）提出。
现状与问题
应用程序最初可能针对桌面Web UI。通常，并行开发后端服务，该后端服务提供该UI所需的功能。随着应用程序用户群的增长，开发了移动端应用程序，必须与同一后端交互。 后端服务成为通用后端，同时满足桌面和移动接口的需求。但是，在屏幕大小，性能和显示限制方面，移动设备的功能与台式浏览器有很大不同。结果，对移动应用程序后端的要求与桌面端有所不同。 这些差异导致增加了对后端的工作量。后端需要进行定期大改才能同时为桌面Web UI和移动应用程序提供服务。通常，每个前端都需要独立的接口团队，导致后端成为开发过程中的瓶颈。多端需求的冲突，以及需要使服务在两个前端均保持正常运行，可能导致后端在单个可部署资源上花费大量精力。 由于开发活动专注于后端服务，因此可能会创建一个单独的团队来管理和维护后端。最终，这导致了界面与后端开发团队之间的脱节，给后端团队带来了负担，以平衡不同前端团队的需求。当一个接口进行更改时，必须先与其他前端团队一起验证这些更改，然后才能将其集成到后端中。
解决方案
每个用户界面创建一个后端。微调每个后端的行为和性能，使其最符合前端环境的需求，而不必担心会影响其他前端体验。
由于每个后端特定于一个接口，因此可以针对该接口进行优化。因此，与试图满足所有接口要求的通用后端相比，它将更小，更简单并且可能更快。每个接口团队都有自主权来控制自己的后端，并且不依赖公共的后端开发团队。这使接口团队可以灵活地选择语言，发布节奏，确定工作负载的优先级以及在后端集成功能。
更多详细信息，请参考Pattern: Backend for Frontends
问题和注意事项
- 考虑要部署多少个后端。
- 如果不同的接口（例如移动客户端）将发出相同的请求，请考虑是否有必要为每个接口实现一个后端，或者单个后端是否足够。
- 实现此模式时，跨服务的代码可能会重复。
- BFF应仅包含特定于客户端的逻辑和行为。常规业务逻辑和其他全局功能应在应用程序中的其他位置进行管理。
- 考虑一下这种模式可能如何反映在开发团队的职责中。
- 考虑实现此模式将花费多长时间。在继续支持现有的通用后端的同时，建立新后端的努力会招致技术债务吗？
什么时候需要使用这种模式
以下情况适用
- 必须维护共享的或通用的后端服务，并且需要大量的开发开销。
- 您要针对特定客户端接口的需求优化后端。
- 对通用后端进行了定制，以容纳多个接口。
- 语言选择最好适合于其他用户界面的后端。
以下情况不适用
- 当接口向后端发出相同或相似的请求时。
- 仅使用一个接口与后端交互时。
