📚 课程目录第3章 BFF与领域建模的关系

3. BFF与领域建模的关系：BFF作为防腐层、领域模型与视图模型的分离、BFF如何协调多个领域服务

在微服务架构中，前端直接调用领域服务会面临模型耦合、接口碎片化、网络开销高等问题。BFF 层在此时承担起防腐层（Anti-Corruption Layer, ACL）的职责，将前端从领域模型的频繁变更中隔离出来，同时完成视图模型与领域模型的分离，并协调多个领域服务的调用。

3.1 BFF 作为防腐层

防腐层是 Eric Evans 在《领域驱动设计》中提出的核心模式，用于防止外部系统（如前端）的模型“污染”领域模型。BFF 天然适合充当这一角色：

模型隔离：前端不直接依赖领域实体和值对象，而是通过 BFF 获取专为 UI 定制的数据结构。
协议转换：BFF 将领域服务暴露的 gRPC/AMQP/内部 REST 接口转换为前端友好的 HTTP/JSON 或 GraphQL。
版本兼容：当领域服务重构或拆分时，BFF 可保持对外接口不变，前端无需同步修改。

  关键原则：BFF 防腐层只做模型转换与数据聚合，不包含业务规则或领域逻辑。业务规则必须下沉到领域服务中。

3.2 领域模型与视图模型的分离

领域模型（Domain Model）与视图模型（View Model）的分离是 BFF 架构的核心设计原则。两者在关注点、结构和生命周期上存在本质差异：

维度	领域模型	视图模型
关注点	业务规则、不变约束、领域行为	UI 展示、用户交互、数据格式
结构	实体、值对象、聚合根、领域事件	扁平化 DTO、组合字段、枚举转文本
生命周期	与业务事务一致，可能跨多个请求	与页面/组件生命周期绑定
变更频率	低，随业务规则演进	高，随 UI 交互迭代
序列化	可能包含循环引用、延迟加载	纯 JSON 可序列化，无循环引用

实践建议：在 BFF 中为每个前端页面或组件定义独立的 ViewModel，不要复用领域实体。例如，订单列表页的 OrderListItemVO 与订单详情页的 OrderDetailVO 应分别定义，即使它们共享部分字段。

以下是一个典型的视图模型转换示例：

// 领域模型（来自订单服务）
public class OrderEntity {
    private String orderId;
    private String userId;
    private List<OrderItemEntity> items;
    private Money totalAmount;
    private OrderStatus status;       // 枚举：CREATED, PAID, SHIPPED, DELIVERED
    private LocalDateTime createdAt;
    private AddressEntity shippingAddress;
    // 包含领域行为：calculateTotal(), validateItems() 等
}

// 视图模型（在 BFF 中定义）
public class OrderDetailVO {
    private String orderId;
    private String statusText;         // 枚举转中文："已支付"
    private String totalAmountYuan;    // 分转元，保留两位小数
    private List<OrderItemVO> items;
    private String createTimeStr;      // LocalDateTime 转 "2025-03-15 14:30"
    private String receiverName;
    private String receiverPhone;
    private String fullAddress;
    // 无领域行为，纯数据容器
}

3.3 BFF 如何协调多个领域服务

现代前端页面往往需要聚合来自多个领域服务的数据。BFF 作为协调层，负责编排调用顺序、处理依赖关系、合并结果并处理异常。常见的协调模式有三种：

串行编排：按依赖顺序依次调用，前一个服务的结果作为后一个服务的入参。
并行聚合：无依赖关系的服务同时调用，使用 Promise.all 或 CompletableFuture 合并结果。
混合编排：先并行获取基础数据，再串行调用依赖服务，最后合并输出。

避坑指南：BFF 协调多个领域服务时，必须处理部分失败场景。建议为每个下游调用设置超时和熔断，避免单个服务慢响应拖垮整个 BFF 实例。使用 Resilience4j 或 Hystrix 等库实现舱壁隔离。

3.4 协调策略对比

策略	适用场景	优点	缺点
串行编排	服务间存在强依赖关系（如先查用户再查订单）	逻辑清晰，易于调试	响应时间 = 各服务耗时之和
并行聚合	服务间无依赖（如同时查用户信息和系统配置）	响应时间 = 最慢服务耗时	需要处理部分失败和超时
混合编排	先并行获取基础数据，再串行执行依赖操作	兼顾效率与依赖关系	实现复杂度较高

  最佳实践：在 BFF 中为每个聚合接口定义明确的协调策略文档，标注哪些服务可并行、哪些必须串行、超时阈值和降级方案。推荐使用 CompletableFuture（Java）或 asyncio.gather（Python）实现并行调用，配合 thenCompose 处理串行依赖。