📚 课程目录第3章业务领域建模

3. 业务领域建模：如何识别核心域、支撑域和通用域

在微服务架构设计中，服务边界的合理性直接决定了系统的演进成本与运行效率。业务领域建模是回答“该拆成多少个服务”这一问题的核心方法。本章将围绕领域驱动设计（DDD）中的战略设计，系统讲解如何通过事件风暴（Event Storming）识别业务事件，并最终映射出服务候选。

DDD 战略设计将业务领域划分为三个层次，其核心思想是资源聚焦：将最优质的研发资源投入到最具竞争力的业务上。

领域类型	定义	典型特征	微服务策略
核心域	企业最核心、最具差异化的竞争力所在	业务逻辑复杂、变化频繁、不可外包	独立团队、高投入、定制化开发
支撑域	为核心域提供必要支持，但非核心竞争力	业务逻辑中等、可部分复用	内部自研或少量定制
通用域	行业通用、无业务差异化的能力	逻辑标准、变化极少	优先采购或使用开源方案

实践建议：在项目启动阶段，使用“业务价值矩阵”对每个子域进行打分（价值维度：业务贡献度、创新度；复杂度维度：逻辑耦合度、变更频率）。得分最高的子域即为核心域候选。

以电商系统为例：订单履约（涉及库存锁定、支付路由、物流调度）通常是核心域；商品管理（SKU 维护、类目树）可能是支撑域；用户认证（登录、注册、权限）则是典型的通用域，可直接集成 Keycloak 或 Auth0。

事件风暴是一种协作式建模工作坊，由 Alberto Brandolini 提出。它通过“业务事件”作为统一语言，让产品、开发、测试、运营等角色在同一张白板上对齐认知。

元素	颜色（标准）	含义	示例
领域事件	橙色	业务中已经发生的、不可改变的事实	“订单已支付”
命令	蓝色	触发事件的用户操作或系统指令	“提交支付请求”
聚合	黄色	承载业务逻辑的数据与行为单元	“订单聚合”
外部系统/角色	粉色	事件发起者或接收者	“支付网关”、“买家”

关键产出：事件风暴结束后，团队应得到一张包含“事件-命令-聚合”的完整时间线图，以及初步的有界上下文划分草图。

事件风暴产出的有界上下文，天然对应微服务候选。但并非每个有界上下文都需要独立部署为一个微服务。我们需要通过以下规则进行收敛与决策：

以下 SVG 展示了从事件风暴到服务候选的映射过程：

假设我们正在设计一个电商平台的订单履约系统。通过事件风暴工作坊，团队识别出以下关键元素：

领域事件	触发命令	所属聚合	有界上下文
订单已创建	提交订单	订单聚合	订单上下文
库存已锁定	锁定库存	库存聚合	库存上下文
支付已成功	确认支付	支付聚合	支付上下文
物流单已生成	创建运单	物流聚合	物流上下文
订单已发货	确认发货	订单聚合	订单上下文

根据映射规则，我们做出以下决策：

常见误区：不要将“有界上下文”直接等同于“微服务”。如果两个上下文变更频率相同、数据强一致、且由同一团队维护，合并为一个服务可以降低运维复杂度。微服务的粒度应随团队规模和业务复杂度动态调整。

业务领域建模是微服务架构设计的起点。通过领域划分（核心域/支撑域/通用域）明确资源投入优先级，借助事件风暴建立统一语言并识别聚合边界，最后根据变更频率、数据独立性、团队结构等维度将有界上下文映射为服务候选。这套方法能够有效避免“一刀切”或“过度拆分”的架构陷阱。