【面试场景题】怎么做业务领域划分

业务领域划分是软件设计（尤其是领域驱动设计DDD）的核心环节，其目标是将复杂业务系统分解为高内聚、低耦合的领域模块，使系统结构与业务逻辑对齐，便于维护、扩展和团队协作。合理的领域划分需要结合业务本质、组织架构和系统演进需求，以下是具体方法和实践步骤：

一、核心原则：以业务为中心，而非技术

领域划分的第一原则是**“业务驱动”**，而非按技术层（如“Controller层”“Service层”）或数据结构划分。核心原则包括：

• 高内聚：同一领域内的业务概念、规则、流程应紧密相关（如“订单”领域应包含订单创建、支付、履约等相关逻辑）。
• 低耦合：不同领域之间通过明确接口交互，避免直接依赖内部实现（如“订单”与“库存”通过“扣减库存”接口交互，而非直接操作库存表）。
• 边界清晰：每个领域有明确的职责范围，避免“一个业务操作跨多个领域无序交织”（如“下单”不应直接修改用户余额，而应调用“支付”领域的接口）。

二、具体步骤：从业务理解到边界定义

1. 深入理解业务：梳理业务全景

领域划分的前提是**“吃透业务”**，需通过以下方式梳理业务本质：

• 访谈业务专家：了解核心业务流程（如电商的“下单→支付→发货→收货”）、业务规则（如“库存不足时不能下单”）、痛点（如“促销活动需快速上线”）。
• 绘制业务流程图：用泳道图、活动图等工具，明确“谁（角色）在什么场景下做什么操作”（如用户、商家、仓库管理员的操作流程）。
• 识别业务实体与事件：记录核心业务对象（如“订单”“商品”“用户”）和关键事件（如“订单创建”“支付成功”“库存扣减”），这些是领域划分的基础。

2. 识别核心领域与支撑领域

根据业务价值和复杂度，将业务系统划分为三类领域，优先保证核心领域的设计质量：

• 核心领域：企业的核心竞争力所在，直接创造业务价值（如电商的“订单履约”“支付结算”，金融的“风控决策”）。
• 支撑领域：支持核心领域运行，但不直接创造核心价值（如“用户管理”“权限控制”“日志审计”）。
• 通用领域：可复用的基础能力（如“通知服务”“缓存服务”“分布式锁”），可封装为公共组件。

示例：电商平台的领域划分

• 核心领域：订单域、商品域、支付域、库存域；
• 支撑领域：用户域、营销域（优惠券/促销）、物流域；
• 通用领域：通知域、搜索域、数据统计域。

3. 划分“限界上下文”：定义领域边界

“限界上下文（Bounded Context）”是DDD中定义领域边界的核心概念，它是一个“语义边界”——内部有统一的业务语言（Ubiquitous Language），外部通过明确接口交互。
划分方法：

• 按业务职责划分：同一职责的业务逻辑归为一个上下文。例如：

• “商品域”可拆分为“商品基础信息上下文”（名称、规格、图片）和“商品定价上下文”（原价、折扣价、会员价），因为“基础信息管理”和“定价策略”是不同职责。

• 按数据边界划分：若一组业务对象的生命周期、数据关联紧密，应放入同一上下文。例如：

• “订单”与“订单项”强关联（订单项依赖订单存在），应属于“订单上下文”；而“订单”与“用户”弱关联（仅记录用户ID），用户信息属于“用户上下文”。

• 按团队组织划分：根据“康威定律”（系统设计反映组织结构），让领域边界与团队职责对齐。例如：

• 若公司有“订单团队”“商品团队”，则按团队负责的业务划分对应的订单域、商品域，减少跨团队协作成本。

• 按变化频率划分：变化频繁的业务与稳定业务分离。例如：

• 电商的“促销规则”（经常变化）应独立为“促销上下文”，而“商品基础信息”（相对稳定）单独为“商品上下文”，避免频繁修改影响稳定部分。

4. 定义领域内的“聚合”：细化内部结构

在限界上下文内部，进一步按“聚合（Aggregate）”划分——聚合是一组紧密关联的业务对象（实体+值对象），作为一个整体处理（如“订单聚合”包含订单、订单项、配送地址）。
聚合划分原则：

• 以“聚合根（Aggregate Root）”为核心：聚合根是对外交互的唯一入口（如订单是聚合根，外部只能通过订单ID操作订单项）。
• 保证事务一致性：聚合内的对象应在同一事务中修改（如创建订单时，需同时创建订单项，确保数据一致）。
• 避免过大聚合：若一个聚合包含过多对象（如超过5-10个），可能导致复杂度上升，需拆分（如“订单”与“订单物流信息”可拆分为两个聚合）。

5. 建立领域间的“上下文映射”：明确交互关系

不同限界上下文之间需通过“上下文映射（Context Mapping）”定义交互方式，避免耦合：

• 合作关系（Partnership）：两个上下文相互依赖，需同步演进（如“订单”与“支付”）。
• 客户-供应商（Customer-Supplier）：上游上下文（供应商）为下游（客户）提供服务，下游依赖上游（如“商品”是“订单”的供应商）。
• 防腐层（Anticorruption Layer）：当集成外部系统（如第三方支付）时，通过防腐层转换外部模型为内部模型，隔离外部变化。
• 发布-订阅（Publish-Subscribe）：通过事件总线异步交互（如“支付成功”事件发布后，“订单”“库存”“物流”订阅并处理）。

三、实践工具：事件风暴（Event Storming）

事件风暴是划分领域的高效实践方法，通过工作坊形式让业务、开发、测试人员协作，快速梳理领域边界：

1. 贴事件：用橙色便签记录所有业务事件（如“订单创建”“支付超时”）。
2. 找命令：用蓝色便签记录触发事件的命令（如“创建订单”命令触发“订单创建”事件）。
3. 定聚合：围绕事件和命令，用黄色便签识别聚合（如“订单聚合”包含“订单创建”“订单取消”等事件）。
4. 划边界：用虚线框将相关的聚合、事件、命令包围，形成限界上下文。

四、常见误区与避坑指南

1. 按技术分层划分领域：如将“数据库操作”“缓存操作”作为领域，这会导致业务逻辑分散在技术层中，难以维护。
2. 过度拆分：将简单业务拆分为过多小领域（如把“用户注册”“用户登录”拆分为两个上下文），增加交互成本。
3. 忽视业务变化：领域划分不是一次性的，需随业务演进调整（如电商从“单仓”到“多仓”，库存域需重新划分）。
4. 边界模糊：若两个领域的职责重叠（如“营销”和“订单”都处理优惠券），需明确“谁是优惠券的所有者”（通常营销域负责发放，订单域负责核销）。

总结

业务领域划分的核心是**“让系统结构跟随业务逻辑自然生长”**：先通过业务理解识别核心价值，再用限界上下文定义边界，最后通过聚合细化内部结构，并结合团队和业务变化持续优化。合理的领域划分能使系统更易理解、扩展和维护，尤其在复杂业务系统（如电商、金融）中，是支撑业务快速迭代的基础。

总结业务领域划分方法论：

1. 核心原则：以业务为中心而非技术，并且保证高内聚、低耦合、边界清晰；
2. 需要深入理解业务，领域内有统一的业务语言，是边界清晰的重要条件。
3. 按业务职责、数据边界、团队组织、变化频率划分。
4. 识别核心领域、支撑领域、通用领域。