DDD子域划分实操讲解（以电商核心业务为例）

DDD中子域划分是领域分析的第一步，是在确定整体领域后，将大的业务领域按照业务职责、业务流程、业务属性拆分为多个更小、更具体的业务单元的过程，这些小单元就是子域。子域是限界上下文界定的直接依据，也是后续领域建模的基础，其划分核心遵循业务导向，而非技术模块划分。

本文以电商零售（线上商城） 为核心案例（最典型、易理解的业务场景），从子域划分核心原则→电商案例实操划分→子域类型标记→拓展案例（新零售电商）→实操技巧&避坑点层层讲解，所有划分逻辑贴合实际业务，可直接落地参考，同时衔接之前的限界上下文、聚合知识点，形成完整体系。

一、先明确：子域划分的3个核心原则（所有场景通用）

划分子域无固定的“标准答案”，但必须遵循3个核心原则，保证划分的合理性、业务贴合性，避免为了拆分而拆分，这是实操的基础：

1. 业务职责单一性原则（核心原则）

一个子域只承担一类独立的业务职责，无职责重叠、无交叉，这是子域划分的第一准则。比如“商品管理”和“订单管理”是完全不同的业务职责，必须拆分为两个独立子域，不能合并。

2. 基于业务流程自然拆解原则

子域划分要贴合实际业务执行流程，而非凭空拆分。比如电商的核心流程是「用户浏览商品→下单→支付→发货→售后」，子域划分可顺着这个流程，将每个核心环节对应的业务职责拆分为独立子域。

3. 兼顾业务粒度与可操作性原则

子域划分的粒度要适配业务复杂度，既不能过粗（一个子域包含多个核心职责，导致后续建模混乱），也不能过细（拆分出大量微小子域，增加交互成本）；小型业务粗粒度划分，大型复杂业务细粒度划分。

补充：子域划分完成后，必须为每个子域标记域类型（核心域/通用域/支撑域），这是后续资源投入、建模优先级的重要依据，也是DDD子域划分的关键环节，三者的核心区别如下：

• 核心域：企业核心竞争力所在的子域，是业务的核心价值环节，优先级最高（如电商的订单、支付、履约子域）；
• 通用域：多个业务领域共用的通用业务子域，无企业独特性，可复用成熟方案（如电商的用户、商品子域，几乎所有互联网业务都有）；
• 支撑域：为核心域、通用域提供辅助支撑的子域，不直接参与核心业务流程，优先级最低（如电商的日志、数据统计、系统权限子域）。

二、核心案例：纯线上电商的子域划分实操

以中小型纯线上电商（如淘宝小店、独立品牌商城）为对象，其业务复杂度适中，适合作为子域划分的入门案例，先定整体领域，再按流程+职责拆解。

步骤1：确定电商的「整体领域」

整体领域为：线上商品零售领域（明确业务的整体边界，聚焦“线上交易”，不包含线下门店、供应链生产等非核心业务）。

步骤2：梳理电商核心业务流程

先梳理用户端+平台端的完整核心业务流程，为子域划分提供脉络：

用户端：注册/登录→商品浏览/搜索→加入购物车→下单→支付→查看物流→收货/售后申请

平台端：商品上架/管理→库存管理→订单处理→支付对接→物流履约→售后审核→数据统计

步骤3：基于原则拆分子域+标记域类型

结合业务流程和职责单一性原则，将电商整体领域拆分为10个核心子域，并标记域类型、明确核心职责，所有子域无职责重叠，边界清晰，具体见下表（最贴合中小型电商的划分方案）：

子域名称	域类型	核心业务职责	业务边界（不包含的内容）
订单子域	核心域	订单创建/修改/取消、订单状态管理、订单明细管理、购物车管理	不包含支付、库存扣减、物流信息更新
支付子域	核心域	支付申请、对接支付渠道（微信/支付宝）、支付结果同步、退款处理	不包含订单创建、订单状态修改
履约子域	核心域	物流单创建、配送商对接、物流轨迹同步、收货确认、发货管理	不包含订单支付、商品库存管理
商品子域	通用域	商品SPU/SKU管理、商品上架/下架/编辑、商品类目/规格管理、商品价格管理	不包含商品库存、商品搜索推荐
库存子域	通用域	可用库存管理、库存预扣减/实际扣减/释放、库存预警、库存盘点	不包含商品信息管理、订单创建
用户子域	通用域	用户注册/登录、用户基础信息管理、收货地址管理、用户等级/积分管理	不包含用户权限、用户行为分析
搜索推荐子域	通用域	商品搜索、个性化商品推荐、搜索关键词管理	不包含商品信息管理、用户行为统计
售后子域	核心域	售后工单创建、退款/换货/维修审核、售后进度管理、售后纠纷处理	不包含支付退款、订单状态修改
系统权限子域	支撑域	平台管理员账号管理、角色权限分配、操作日志管理	不包含用户端权限、业务操作记录
数据统计子域	支撑域	交易数据统计、用户行为统计、商品销量统计、库存数据统计	不包含业务数据存储、数据可视化前端开发

关键说明

1. 此划分方案为中小型电商适配版，将“购物车管理”归为订单子域（因购物车是下单的前置环节，职责强关联），未单独拆分子域，减少交互成本；若为大型电商（如淘宝、京东），可将“购物车子域”单独拆分；
2. 核心域包含订单、支付、履约、售后，这四个子域是电商交易的核心环节，直接决定企业的交易体验和核心竞争力，后续建模需优先投入资源；
3. 通用域的“库存子域”虽为通用业务，但与订单、履约强关联，是核心交易的必要环节，需与核心域同步建模；
4. 支撑域仅做基础划分，无需细化，后续可直接复用成熟的权限、统计方案。

三、拓展案例：新零售电商的子域划分（业务复杂度升级）

当电商业务从纯线上升级为新零售（线上+线下）（如盒马、美团闪购），业务增加了门店管理、线下配送、门店库存等环节，业务复杂度提升，此时需在纯线上电商子域的基础上，按职责新增子域+微调原有子域边界，体现子域划分的灵活性。

新零售电商新增子域+域类型标记

新增子域名称	域类型	核心业务职责	新增原因
门店子域	核心域	门店基础信息管理、门店营业时间/营业状态管理、门店类目管理、门店员工管理	新零售核心是“线上+线下”，门店为核心载体
门店库存子域	通用域	门店商品库存管理、门店库存与线上库存同步、门店库存盘点	线下门店库存与线上仓库库存职责分离
即时配单子域	核心域	同城即时配送调度、骑手管理、配送轨迹同步、配送时效管理、配送费用计算	新零售的核心竞争力是“即时履约”
会员营销子域	核心域	会员等级管理、优惠券/满减活动创建、营销活动投放、会员消费统计	新零售的核心获客/留客手段

原有子域边界微调

1. 将原“履约子域”重命名为仓库履约子域，仅负责线上仓库的发货配送，与即时配单子域形成“仓配+店配”的双重履约体系；
2. 将原“数据统计子域”的部分职责（门店交易统计、骑手配送统计）拆分至对应子域，保证职责单一。

核心结论：子域划分随业务范围、业务复杂度动态调整，核心始终是贴合业务职责，新增业务环节则新增对应子域，职责分离则微调边界，不追求一成不变。

四、子域划分与后续DDD环节的关联（衔接之前知识点）

子域划分是DDD领域分析的第一步，其结果直接决定后续的建模方向，与之前讲解的限界上下文、聚合形成清晰的层级关系，也是微服务拆分的基础，核心关联如下：

1. 子域 → 限界上下文：一个子域对应一个或多个限界上下文（中小型业务：子域与限界上下文一对一映射，如订单子域→订单限界上下文；大型复杂业务：一个子域拆分为多个限界上下文，如大型电商的订单子域→普通订单限界上下文+预售订单限界上下文）；
2. 限界上下文 → 聚合：一个限界上下文包含一个或多个聚合，聚合是限界上下文内部的对象组合单元；
3. 子域 → 微服务：子域是微服务拆分的粗粒度依据，限界上下文是微服务拆分的细粒度依据，最终微服务的边界与限界上下文对齐，而限界上下文由子域界定。

通俗层级关系：整体领域 → 子域（按职责拆分）→ 限界上下文（子域的业务边界）→ 聚合（限界上下文内的对象单元）→ 领域对象（聚合的组成）。

五、子域划分的实操技巧+常见避坑点

实操技巧（落地性优先）

1. 跨职能团队协作划分：由业务人员+产品+架构师共同参与，业务人员界定业务职责和边界，产品梳理业务流程，架构师把控拆分粒度，避免技术人员单独按技术模块划分；
2. 先粗后细，逐步迭代：先做粗粒度划分，确定核心子域和域类型，后续随业务理解的深入、业务复杂度的提升，再对核心子域做细粒度拆分，不追求一步到位；
3. 用可视化工具梳理边界：用ProcessOn、DrawIO等工具绘制子域关系图，标注每个子域的核心职责、域类型，以及子域之间的关联关系（如订单子域依赖库存、商品子域），便于团队共识。

常见避坑点（实操高频错误）

1. 按技术模块而非业务职责划分：典型错误如将“前端子域”“后端子域”“数据库子域”作为划分结果，完全脱离业务，导致后续建模无法贴合实际；
2. 子域职责重叠：如将“库存管理”归为商品子域，导致商品子域同时承担“商品信息管理”和“库存管理”两个核心职责，后续限界上下文界定模糊；
3. 过度拆分微小子域：如将“订单创建”“订单修改”“订单取消”拆分为三个独立子域，属于同一业务职责的不同操作，拆分后增加交互成本，无实际意义；
4. 忽略域类型标记：仅拆分子域但不标记核心/通用/支撑域，导致后续建模资源投入无优先级，将大量精力投入到通用域/支撑域，忽略核心域的精细化建模。

六、子域划分核心总结

DDD子域划分的本质是对企业业务的“职责拆解与边界界定”，核心始终围绕业务展开，所有划分动作都要回答两个问题：这个子域承担什么独立的业务职责？/这个子域与其他子域的业务边界在哪里？。

其核心价值在于：

1. 让团队对企业的业务体系形成结构化的认知，避免对业务的理解停留在零散的需求层面；
2. 为后续限界上下文、聚合的设计提供清晰的业务基础，是DDD领域建模的“地基”；
3. 通过域类型标记明确企业核心竞争力，让后续的开发、建模资源向核心域倾斜，保证企业核心业务的精细化设计。

无论是电商、金融、物流还是其他行业，子域划分的原则和方法都通用，只需结合自身业务的流程、职责、复杂度做适配调整即可。