2. 领域边界定义：领域边界、限界上下文在BFF中的应用、上下文映射图
在EntBFF架构中，领域边界是划分业务能力与数据所有权的最基本单位。没有清晰的边界，BFF层会退化为“万能胶水层”，导致耦合爆炸、变更扩散和团队协作混乱。本节从领域边界的本质出发，逐步展开限界上下文（Bounded Context）在BFF中的落地策略，以及如何通过上下文映射图（Context Map）管理跨边界协作。
2.1 什么是领域边界
领域边界（Domain Boundary）是DDD中用于界定业务逻辑、数据模型和团队职责的显式分界线。每条边界内部拥有完整的通用语言（Ubiquitous Language）和独立的业务规则，边界之间通过契约进行通信。
| 维度 | 边界内部 | 边界外部 |
|---|---|---|
| 通用语言 | 统一、无歧义 | 可能同名不同义 |
| 数据模型 | 独立演进 | 通过DTO/API转换 |
| 业务规则 | 内聚、自治 | 不直接依赖 |
| 团队归属 | 单一团队拥有 | 跨团队协商 |
| 部署单元 | 可独立部署 | 通过API网关聚合 |
关键原则：领域边界不是技术分层（如Controller/Service/Repository），而是业务概念的逻辑隔离。在BFF中，边界决定了哪些接口可以合并、哪些必须分离。
2.2 限界上下文（Bounded Context）在BFF中的应用
限界上下文是领域边界的DDD实现载体。每个限界上下文对应一个明确的业务子域，拥有独立的模型、数据库和API契约。在BFF设计中，限界上下文直接决定了BFF接口的聚合粒度与路由策略。
2.2.1 BFF中的三种上下文关系模式
- 一对一模式：一个BFF接口只映射到一个限界上下文。适用于高内聚、低耦合的核心子域（如订单、支付）。
- 聚合模式：一个BFF接口聚合多个限界上下文的数据。适用于仪表盘、首页等需要跨域组合的场景，但必须通过编排层（Orchestration）而非直接耦合。
- 防腐层模式：BFF作为下游限界上下文的防腐层（Anti-Corruption Layer），对上游遗留系统或第三方API进行模型转换与协议适配。
| 模式 | 适用场景 | BFF职责 | 风险 |
|---|---|---|---|
| 一对一 | 核心业务操作（下单、退款） | 透传+轻量转换 | 接口碎片化 |
| 聚合 | 组合查询（用户主页、订单列表） | 编排+数据合并 | 编排复杂度 |
| 防腐层 | 对接旧系统、第三方服务 | 模型映射+协议适配 | 维护成本 |
实践建议：在EntBFF中优先采用“一对一”模式，仅在明确存在跨域组合需求时才使用“聚合模式”，且聚合逻辑必须独立为BFF编排服务，避免污染接口层。
2.2.2 限界上下文在BFF接口设计中的落地步骤
- 识别子域：与业务专家协作，将业务域拆分为核心子域、支撑子域和通用子域。
- 分配限界上下文：每个子域对应一个限界上下文，定义其通用语言和聚合根。
- 设计BFF接口边界：每个限界上下文暴露一组RESTful或gRPC接口，BFF按前端场景（Web/iOS/Android）进行二次聚合。
- 定义上下文映射：明确BFF与每个限界上下文之间的协作关系（如合作伙伴、防腐层、开放主机服务）。
2.3 上下文映射图（Context Map）
上下文映射图是DDD中用于可视化限界上下文之间协作关系的工具。在EntBFF架构中，上下文映射图帮助团队看清：BFF与哪些限界上下文交互、交互模式是什么、数据流向如何。
2.3.1 上下文映射的常用协作模式
| 模式 | 描述 | BFF中的典型用法 |
|---|---|---|
| 合作伙伴（Partnership） | 两个上下文协同演进，互相依赖 | BFF与订单上下文联合发布新接口 |
| 共享内核（Shared Kernel） | 共享部分模型，但需严格控制变更 | BFF与支付上下文共享支付状态枚举 |
| 客户-供应商（Customer-Supplier） | 上游决定，下游适配 | BFF适配用户上下文的身份认证接口 |
| 防腐层（Anti-Corruption Layer） | 下游创建转换层隔离上游变化 | BFF对接旧ERP订单系统 |
| 开放主机服务（Open Host Service） | 上下文暴露标准化API供外部调用 | 订单上下文暴露RESTful API给BFF |
常见误区：不要将上下文映射图画成系统架构图（如微服务部署图）。上下文映射图关注的是业务模型之间的协作关系，而非技术通信协议。BFF中的上下文映射应聚焦于“哪个上下文负责哪个业务能力”，而不是“哪个服务调用哪个服务”。
2.4 领域边界在EntBFF中的落地检查清单
- 边界完整性：每个BFF接口是否都能追溯到唯一的限界上下文？
- 模型独立性：不同限界上下文之间是否存在模型泄漏（如订单上下文直接使用用户实体的字段）？
- 接口契约化：BFF与限界上下文之间是否通过版本化API契约通信？
- 团队对齐：每个限界上下文是否对应一个明确的团队或小组？
- 映射可视化：团队是否维护了最新的上下文映射图，并在接口变更时同步更新？