3. EntBFF 架构总览：企业级 BFF 的整体架构分层、与微服务、API Gateway 的关系
企业级 BFF（EntBFF）并非一个孤立的中间层，而是嵌入在微服务架构体系中的关键枢纽。理解 EntBFF 的架构分层及其与上下游组件（API Gateway、微服务）的协作关系，是设计业务接口领域边界的前提。本章从宏观视角拆解 EntBFF 的层次结构，并明确其在整个调用链中的定位。
3.1 整体架构分层
EntBFF 采用四层逻辑架构，从外到内依次为：接入层、编排层、领域聚合层、基础设施层。每一层职责清晰，边界严格，确保业务逻辑不泄露。
| 层次 | 核心职责 | 典型组件/技术 | 关键约束 |
|---|---|---|---|
| 接入层 | 协议适配、认证鉴权、流量控制、请求/响应转换 | Spring Cloud Gateway、Kong、自定义 Filter | 不包含任何业务逻辑，仅做透传与安全校验 |
| 编排层 | 跨微服务的数据聚合、流程编排、事务补偿 | 编排引擎、工作流、异步消息 | 只负责组合，不修改领域数据；无状态 |
| 领域聚合层 | 业务规则校验、领域对象组装、接口语义映射 | DDD 聚合根、领域服务、Repository 接口 | 核心业务逻辑所在，禁止直接依赖外部服务 |
| 基础设施层 | 微服务调用、缓存、数据库、消息队列 | Feign Client、Redis、MyBatis、RocketMQ | 技术实现细节，对上层提供 SPI 接口 |
架构原则：每一层只能依赖其直接下层。例如，编排层可以调用领域聚合层，但不能直接调用基础设施层的 Feign Client。这种分层隔离保证了业务逻辑与技术实现的解耦。
3.2 EntBFF 与 API Gateway 的关系
API Gateway 与 EntBFF 在微服务架构中承担不同角色，常被混淆。下表从多个维度进行对比：
| 对比维度 | API Gateway | EntBFF |
|---|---|---|
| 关注点 | 基础设施与安全 | 业务编排与领域语义 |
| 路由粒度 | URL 路径、Header、方法 | 业务场景、用户角色、设备类型 |
| 状态管理 | 无状态，纯代理 | 可持有会话状态（如用户上下文） |
| 业务逻辑 | 禁止包含 | 核心业务编排与聚合 |
| 典型部署 | 集群边缘，独立部署 | 业务域内，与微服务同集群 |
| 变更频率 | 低（配置变更为主） | 高（随业务需求迭代） |
在实际部署中，API Gateway 位于 EntBFF 之前，作为流量的统一入口。Gateway 完成安全校验与路由分发后，将请求转发至对应的 EntBFF 实例。EntBFF 再根据业务场景调用下游微服务。
3.3 EntBFF 与微服务的关系
EntBFF 是微服务的“业务门面”，而非简单的代理。其核心差异在于：
- 接口语义化：微服务暴露的是资源型接口（如
/orders/{id}），EntBFF 将其转化为业务语义接口（如/checkout）。 - 数据聚合：一个 EntBFF 接口可能聚合 3~5 个微服务的数据，并完成字段裁剪、格式转换。
- 业务规则下沉：EntBFF 的领域聚合层承载了跨微服务的业务规则（如“下单前校验用户信用额度”），这些规则不适合放在微服务内部。
常见误区：不要将 EntBFF 视为“微服务的 API 聚合器”。如果 EntBFF 只是简单调用多个微服务并拼接 JSON，那它退化为一个无价值的透传层。EntBFF 必须包含领域逻辑，才能体现其业务边界价值。
3.4 架构总览图
下图展示了 EntBFF 在微服务架构中的完整位置与内部分层：
3.5 调用链路示例
以一个典型的“用户下单”场景为例，展示 EntBFF 如何串联各层与微服务：
- 客户端请求 →
POST /api/v1/orders到达 API Gateway。 - API Gateway 校验 Token、限流，根据路径前缀
/api/v1/orders路由至 EntBFF 实例。 - EntBFF 接入层 解析 Header 中的用户 ID 与设备信息，构建请求上下文。
- EntBFF 编排层 调用领域聚合层的
CreateOrderService，该服务内部：- 通过基础设施层调用 用户微服务 校验信用额度。
- 调用 库存微服务 锁定商品库存。
- 调用 订单微服务 创建订单记录。
- 调用 支付微服务 生成支付链接。
- 领域聚合层 将各微服务返回的数据组装为统一的
OrderCreateResponse对象。 - EntBFF 接入层 将响应序列化为 JSON，返回给客户端。
关键设计点：在上述链路中，EntBFF 的领域聚合层承担了“信用校验”这一业务规则，该规则不属于任何一个微服务的原子能力，而是跨微服务的业务约束。这正是 EntBFF 作为业务接口领域边界的核心价值。
3.6 架构分层与微服务的关系图
下图进一步细化 EntBFF 内部各层与微服务之间的依赖关系，突出“领域聚合层”作为业务规则中心的地位：
3.7 关键设计原则
- 单向依赖：EntBFF 内部各层严格单向依赖，避免循环引用。领域聚合层不直接持有 Feign Client 或 RedisTemplate，而是通过基础设施层定义的接口进行调用。
- 无状态编排：编排层不保存业务状态，所有状态（如用户会话、事务上下文）由领域聚合层管理或透传。
- 接口契约优先：EntBFF 与微服务之间的接口定义（DTO、Feign 接口）应作为独立契约管理，变更时需同步版本号，避免运行时断裂。
- 可观测性：每一层都需要输出结构化日志与指标，便于在分布式追踪中定位瓶颈。EntBFF 的调用链跨度通常比普通微服务更长，更需关注。
实践建议：在项目初期，先定义 EntBFF 与微服务之间的接口契约（OpenAPI 或 Protobuf），再分别实现。这能有效避免后期因接口不一致导致的联调返工。