2. BFF 领域边界定义
在微服务架构中，领域边界是指一个子系统或模块所负责的业务职责范围，它划定了“什么属于我，什么不属于我”。BFF（Backend For Frontend）作为一个独立的架构层，其领域边界必须清晰定义，否则会导致职责混乱、耦合加剧、维护成本飙升。
2.1 什么是领域边界
领域边界源自领域驱动设计（DDD）中的限界上下文概念。每个限界上下文拥有自己的通用语言、数据模型和业务规则，与其他上下文通过明确的接口进行交互。在微服务架构中，领域边界通常表现为：
- 数据所有权：每个服务拥有自己的数据库或数据存储，禁止直接访问其他服务的数据库。
- 业务逻辑封装：服务内部的业务规则对外部不可见，仅通过 API 暴露能力。
- 独立演进：服务可以在不影响其他服务的前提下独立部署、升级和扩展。
关键认知：领域边界不是物理隔离，而是逻辑契约。边界两侧通过 API 契约通信，契约的稳定性决定了架构的健壮性。
2.2 BFF 在微服务架构中的定位
BFF 位于客户端与后端微服务之间，是一个轻量级的中间层。它的核心定位是：为每一种前端客户端（Web、iOS、Android、小程序等）提供专属的 API 聚合与适配层。
以下表格对比了 BFF 与传统 API 网关、直接调用微服务的差异：
| 维度 | 直接调用微服务 | 传统 API 网关 | BFF |
|---|---|---|---|
| 职责范围 | 业务逻辑 + 数据 | 路由、限流、认证 | 聚合、编排、适配 |
| 客户端感知 | 感知所有微服务 | 感知网关地址 | 感知 BFF 地址 |
| 数据裁剪 | 返回完整数据 | 有限转换 | 按需裁剪 |
| 协议适配 | 固定协议 | 协议转换 | 按客户端定制 |
| 团队归属 | 后端团队 | 平台/运维团队 | 前端团队或专属 BFF 团队 |
2.3 BFF 的核心职责
BFF 的职责可以归纳为以下五个方面：
- API 聚合：将多个微服务的接口调用合并为一个 BFF 接口，减少客户端请求次数。
- 数据裁剪：只返回客户端真正需要的数据字段，避免过度传输。
- 协议适配：将后端微服务的内部协议（如 gRPC、Thrift）转换为客户端友好的 REST 或 GraphQL。
- 编排与组合：处理跨微服务的业务逻辑编排，如先调用用户服务获取信息，再调用订单服务获取订单列表。
- 客户端专属逻辑：处理特定客户端的 UI 状态、缓存策略、错误码映射等。
最佳实践：BFF 不应包含核心业务逻辑。如果某个逻辑需要被多个 BFF 复用，应下沉到共享的微服务或公共库中。
2.4 BFF 领域边界示意图
下图展示了 BFF 在微服务架构中的位置及其与客户端、后端微服务的关系：
2.5 BFF 的职责边界清单
为了帮助团队在实际项目中划定 BFF 的领域边界，以下清单列出了 BFF 的应做与不应做：
| 类别 | 应做（BFF 职责内） | 不应做（BFF 职责外） |
|---|---|---|
| 数据 | 聚合、裁剪、格式化 | 持久化存储、数据清洗 |
| 业务 | 编排、组合、转换 | 核心业务规则、计算引擎 |
| 安全 | Token 校验、权限过滤 | 用户注册、密码加密 |
| 通信 | 协议适配、超时控制 | 消息队列消费、事件溯源 |
| 状态 | 会话缓存、客户端状态 | 全局分布式事务、长事务 |
2.6 领域边界划分原则
在实际项目中，划分 BFF 的领域边界应遵循以下原则：
- 按客户端类型划分：不同客户端（Web、移动端、IoT）的交互模式不同，应各自拥有独立的 BFF。
- 按业务域划分：如果某个 BFF 变得过于庞大，可以按业务域拆分为多个 BFF（如订单 BFF、用户 BFF）。
- 按变更频率划分：将变更频繁的客户端逻辑与稳定的后端逻辑分离，避免频繁部署影响全局。
- 按团队归属划分：BFF 应由对应的前端团队或专属 BFF 团队维护，避免跨团队协调瓶颈。
常见误区：不要将 BFF 当作“万能中间层”。如果 BFF 中出现了大量 if-else 判断客户端类型、或者直接操作数据库，说明领域边界已经失守，需要重构。
2.7 BFF 与微服务的协作流程
下图展示了 BFF 在一次典型请求中的协作流程：
2.8 本章小结
- 领域边界是微服务架构中职责划分的核心概念，BFF 的边界应清晰定义。
- BFF 位于客户端与微服务之间，职责包括聚合、裁剪、适配、编排。
- BFF 不应包含核心业务逻辑、持久化存储或全局事务。
- 划分 BFF 边界时应考虑客户端类型、业务域、变更频率、团队归属。
- 清晰的领域边界是后续 API 契约设计的基础，也是保证架构演进灵活性的前提。