3. 限界上下文与模块边界：如何通过业务能力识别限界上下文，划分模块边界

在微服务与中台架构中，最常被问及的问题是：“一个业务功能应该拆成几个服务？边界在哪里？”答案的核心在于限界上下文（Bounded Context）。它是领域驱动设计（DDD）的战略设计核心，也是模块拆分的“第一性原理”。

3.1 什么是限界上下文？

限界上下文定义了模型的应用范围。在一个上下文中，领域模型是统一且自洽的；超出这个边界，模型的含义可能发生变化。它是模块拆分的最小业务单元。

3.2 如何通过业务能力识别限界上下文？

识别过程遵循“业务能力 → 业务子域 → 限界上下文”的逐层分解路径。以下是经过大量企业实战验证的四步法：

1. 梳理业务能力全景图：与业务专家一起，列出企业所有核心业务能力（如：客户管理、商品上架、订单处理、库存调度、财务核算）。
2. 划分业务子域：将业务能力按“核心域”、“支撑域”、“通用域”归类。核心域是企业的竞争优势（如电商的“交易”），支撑域是必要但不独特（如“仓储”），通用域可采购（如“认证”）。
3. 寻找语言分歧点：识别不同角色对同一术语的不同理解。例如，“客户”在销售部指“潜在客户”，在客服部指“已成交客户”。语言分歧就是边界。
4. 验证内聚性与耦合度：检查候选上下文内部是否高内聚（一个变更理由只影响本上下文），上下文之间是否低耦合（通过事件或API通信，不共享数据库）。

3.3 限界上下文与模块边界的映射关系

在代码层面，一个限界上下文通常对应一个独立的模块（Module）或微服务（Microservice）。映射时需遵循以下原则：

• 一对一原则：一个限界上下文原则上只产出一个部署单元（JAR包、Docker镜像）。
• 防腐层（ACL）：在上下文之间建立转换层，防止外部模型的“污染”。例如，订单上下文调用支付上下文时，通过ACL将支付DTO转换为订单内部的支付值对象。
• 共享内核（Shared Kernel）：仅当两个上下文确实需要共享少量核心概念（如“货币类型”、“国家代码”）时，才抽取公共库，且必须严格控制变更。

下图展示了电商系统中典型的限界上下文划分及其模块边界：

3.4 模块边界划分的常见模式

在实际划分时，以下三种模式被广泛采用，可根据团队规模和业务复杂度选择：

3.5 实战案例：从业务能力到模块边界

以一家在线教育平台为例，演示完整的识别与划分过程：

1. 业务能力清单：课程管理、讲师管理、学员管理、订单交易、视频播放、考试测评、证书发放、营销活动。
2. 子域归类：
   • 核心域：课程管理（内容质量决定平台竞争力）、订单交易（收入来源）。
   • 支撑域：讲师管理、学员管理、考试测评、证书发放。
   • 通用域：视频播放（可使用第三方SDK）、营销活动（可采购营销引擎）。
3. 语言分歧识别：
   • “课程”在课程管理上下文指“课程大纲+章节+资料”，在订单上下文指“一个可购买的商品SKU”。
   • “学员”在学员管理上下文指“个人档案+学习记录”，在营销上下文指“一个可触达的用户ID”。
4. 最终模块划分：
   • course-service：课程管理上下文（核心域）
   • order-service：订单交易上下文（核心域）
   • instructor-service：讲师管理上下文（支撑域）
   • learner-service：学员管理上下文（支撑域）
   • exam-service：考试测评上下文（支撑域）
   • certificate-service：证书发放上下文（支撑域）
   • video-service：视频播放上下文（通用域，封装第三方SDK）
   • promotion-service：营销活动上下文（通用域）

每个服务拥有独立数据库，通过API网关对外暴露接口，服务间通过事件总线（如Kafka）进行异步通信，确保核心域的高可用与支撑域的弹性扩展。