领域驱动 - 战略设计实践

文章目录

[领域驱动 - 战略设计实践](#领域驱动 - 战略设计实践)
- 前言
- 一、项目背景与业务挑战
- - [1.1 企业背景](#1.1 企业背景)
  - [1.2 核心业务挑战](#1.2 核心业务挑战)
- 二、战略方向设计
- - [2.1 业务目标确定](#2.1 业务目标确定)
  - [2.2 实现路径选择](#2.2 实现路径选择)
  - [2.3 轻量化定位](#2.3 轻量化定位)
- 三、统一语言建立
- - [3.1 术语收集](#3.1 术语收集)
  - [3.2 业务对齐](#3.2 业务对齐)
- 四、领域边界划分
- - [4.1 核心域识别（业务核心竞争力）](#4.1 核心域识别（业务核心竞争力）)
  - [4.2 通用域识别（各业务通用能力）](#4.2 通用域识别（各业务通用能力）)
  - [4.3 支撑域识别（基础设施能力）](#4.3 支撑域识别（基础设施能力）)
  - [4.4 外部防腐层（Anti-Corruption Layer）](#4.4 外部防腐层（Anti-Corruption Layer）)
  - [4.5 领域汇总与限界上下文映射](#4.5 领域汇总与限界上下文映射)
- 五、微服务拆分
- - [5.1 什么是限界上下文](#5.1 什么是限界上下文)
  - [5.2 服务拆分粒度：从领域到限界上下文](#5.2 服务拆分粒度：从领域到限界上下文)
  - - 为什么没有拆到限界上下文？
    - [领域 vs 限界上下文](#领域 vs 限界上下文)
  - [5.3 服务列表](#5.3 服务列表)
  - [5.4 服务依赖拓扑图](#5.4 服务依赖拓扑图)
  - [5.5 服务拆分决策矩阵](#5.5 服务拆分决策矩阵)
  - - [5.5.1 核心域决策](#5.5.1 核心域决策)
    - [5.5.2 通用域决策](#5.5.2 通用域决策)
    - [5.5.3 支撑域决策](#5.5.3 支撑域决策)
    - [5.5.4 外部防腐层决策](#5.5.4 外部防腐层决策)
    - [5.5.5 决策因素说明](#5.5.5 决策因素说明)
- 六、总结与经验
- - [6.1 实践要点回顾](#6.1 实践要点回顾)
  - [6.2 关键设计决策与经验教训](#6.2 关键设计决策与经验教训)
- 结语

领域驱动 - 战略设计实践

前言

领域驱动设计（DDD）的战略设计阶段，是将业务需求转化为技术架构的关键桥梁。本文以一个供应链企业的ERP系统为实际案例，呈现从业务调研到微服务拆分的完整实践过程，为读者提供可复用的DDD战略设计方法论参考。

一、项目背景与业务挑战

1.1 企业背景

某供应链企业在数字化转型过程中面临着多系统整合的挑战，企业原有多个分散的业务系统：

多个品牌的ERP系统并行运行
各系统业务流程不统一
数据孤岛现象严重
维护成本逐年增高

1.2 核心业务挑战

挑战	描述
业务流程不一致	各系统的业务流程不统一，存在各自为政的现象
数据孤岛	各系统数据无法互通，形成信息孤岛
融合成本	需要考虑各业务系统的兼容性和迁移成本
技术债务	遗留系统技术栈老旧，维护困难

这些挑战促使企业开始思考：如何将多个系统整合为一个统一的企业ERP？

二、战略方向设计

2.1 业务目标确定

团队首先明确系统目标：

统一业务入口 ------ 为各业务线提供统一的ERP服务
数据贯通 ------ 实现各业务线数据的互通互联
能力复用 ------ 沉淀核心业务能力，避免重复建设

2.2 实现路径选择

面对多系统融合的问题，团队提出了四种可能的解决路径：

方案	思路	优点	缺点
方案一	各系统独立运行	改动最小	无法根本上解决问题
方案二	新系统向现有系统靠拢	统一到现有流程	新系统需要大改
方案三	现有系统向新系统靠拢	统一到新系统	现有系统改动大
方案四	建立新的标准流程	一劳永逸	需要顶层设计投入

经过综合评估，最终选择了方案四：重新定义流程，建立新的标准化业务流程。

关键洞察：涉及多业务线融合的系统，必须从公司战略层面决策，需要领导层的参与和支持。

2.3 轻量化定位

在战略设计阶段，团队明确了系统的轻量化定位：

能力域	实现策略
订单/客户/采购/商品	完全自研，核心竞争力
仓储模块	WMS代理服务对接外部WMS，ERP内部做指令单据和库存管理
仓库作业	自研，仓储指令单据管理
库存	自研，ERP内部库存管理
结算	ERP内部结算+财务代理服务对接外部财务
账号体系	完全自研，用于系统登录认证

核心架构：ERP内部仓储/财务指令 → 代理服务 → 外部系统

三、统一语言建立

3.1 术语收集

DDD的核心原则之一是统一语言（Ubiquitous Language），即业务人员和技术人员使用相同的术语进行沟通。

团队通过业务调研，收集了各领域的核心术语（以下为部分示例，参照主流ERP系统）：

领域	术语	英文	定义
账号	用户账号	User Account	系统登录账号
账号	角色	Role	账号对应的权限角色
账号	权限	Permission	账号拥有的功能权限
采购	供应商	Vendor	采购交易的供应商主体
采购	供应商组	Vendor Group	供应商分组，便于批量管理
采购	采购订单	Purchase Order	采购业务单据
仓储	仓库	Warehouse	物理仓库
仓储	库位	Location	仓库内具体库位
仓储	站点	Site	业务运营站点
仓储指令	入库单	Inbound Receipt	入库指令单据
仓储指令	出库单	Picking List	出库指令单据
仓储指令	组拆单	Assembly Order	组合/拆卸指令单据
仓储指令	库存预留	Inventory Reservation	库存预留/冻结
销售	销售订单	Sales Order	销售业务单据
销售	销售渠道	Sales Channel	销售渠道
销售	客户	Customer Account	购买方客户
客户	客户等级	Customer Group	客户分类
商品	物料	Item	销售商品主体
商品	SKU	Product Variant	商品规格变体
商品	多维度	Product Dimension	商品规格属性
财务	应收款	Accounts Receivable	应收账款
财务	收款	Payment Journal	收款单据
财务	发票	Invoice	发票管理
财务	账期	Payment Term	客户回款账期
财务	成本	Cost	商品成本核算
财务	利润	Profit	利润计算
财务	科目	Account	会计科目
仓储	批次	Batch	商品批次管理
仓储	效期	Expiry Date	商品有效期
仓储	库龄	Stock Age	库存在库时长
仓储	容器	Container	仓储容器/箱体
订单	履约	Fulfillment	订单履约流程
订单	状态机	State Machine	订单状态流转
订单	促销	Promotion	促销策略
采购	入库	Receiving	采购入库
采购	退货	Purchase Return	采购退货

说明：以上术语表为战略设计阶段收集的部分核心术语，并非完整术语清单。完整的术语表需要在后续需求分析阶段与各业务部门深度调研后逐步完善。

3.2 业务对齐

收集到的术语需要与业务部门逐一确认和对齐：

消除歧义：确认同一术语在不同业务部门是否含义一致
统一命名：统一相同含义的术语命名
补充遗漏：识别业务中存在但尚未收集的术语

四、领域边界划分

DDD中通常将领域划分为核心域 、通用域 和支撑域三类。不同类型的领域在业务价值、技术实现上有所区别，因此我们从领域类型角度出发，逐一识别各领域的边界，并映射到具体的服务。

术语说明 ：在DDD中，领域（Domain）是业务边界的最大划分，每个独立领域有自己明确的业务范围和职责。核心域包含多个独立领域（如订单、采购、商品），每个领域内部可进一步划分为子域（Subdomain）（如订单领域的履约子域、促销子域）。本文当前拆分粒度为"领域"层级。

4.1 核心域识别（业务核心竞争力）

核心域是企业最核心的业务，直接支撑企业的商业成功，必须完全自研。

领域	英文	识别理由	对应服务
销售领域	Order	销售订单是企业收入的源头，业务逻辑复杂（状态机、促销、履约），需要高频迭代	erp-order
客户领域	Customer	客户是企业最重要的资产，需要独立管理经销商档案、信用额度、等级体系	erp-customer
采购领域	Purchasing	采购直接影响成本和供应链稳定，需要管理供应商、议价、采购订单	erp-purchasing
商品领域	Goods	商品是销售和采购的标的，需要管理SKU、多维度属性、价格体系	erp-goods
企业领域	Enterprise	多组织架构是企业运营的基础，订单、客户、采购都需要归属到企业主体	erp-enterprise

4.2 通用域识别（各业务通用能力）

通用域是被多个核心域共用的能力，不直接创造差异化价值，但不可或缺。

领域	英文	识别理由	对应服务
结算领域	Settlement	应收、收款、发票、账期是财务核心能力，被订单、采购共用	erp-settlement
仓储指令领域	Warehouse Operations	仓储指令（入库单、出库单、调拨、组拆、BOM、库存移动）是仓储核心能力，被订单、采购、内部调拨共用	erp-warehouse-ops
库存领域	Inventory	库存状态（冻结、预留、扣减）被订单、仓储指令、采购共用	erp-inventory

4.3 支撑域识别（基础设施能力）

支撑域是支撑核心域和通用域运行的基础能力，通常具有通用性。

领域	英文	识别理由	对应服务
账号领域	Account	用户账号、角色、权限是所有系统的基础安全能力	erp-account
认证领域	Auth	JWT签发、Token验证是统一的身份认证能力	erp-auth
基础领域	Base	通用枚举、工具类、配置是所有服务共用的基础能力	erp-base

4.4 外部防腐层（Anti-Corruption Layer）

外部防腐层负责与外部系统交互，通过防腐层（ACL）隔离外部系统变化对内部领域的影响。

领域	英文	识别理由	对应服务
WMS代理领域	WMS Agent	对接外部WMS系统，封装外部系统接口差异	erp-wms-agent
财务代理领域	Finance Agent	对接外部财务系统，封装外部系统接口差异	erp-finance-agent

4.5 领域汇总与限界上下文映射

将上述识别结果汇总，并映射到限界上下文：
外部防腐层
通用域
核心域
依赖
依赖
依赖
归属
依赖
依赖
关联
关联
支撑域
Account

账号体系 - erp-account
Auth

身份认证 - erp-auth
Base

基础能力 - erp-base
Order

销售订单 - erp-order
Customer

客户管理 - erp-customer
Purchasing

采购管理 - erp-purchasing
Goods

商品管理 - erp-goods
Enterprise

企业主体 - erp-enterprise
Settlement

结算 - erp-settlement
WarehouseOps

仓储指令 - erp-warehouse-ops
Inventory

库存 - erp-inventory
WMS Agent

防腐层 - erp-wms
Finance Agent

防腐层 - erp-finance-agent

图解说明：

核心域（5个领域）：订单、客户、采购、商品、企业 ------ 直接支撑业务营收

通用域（3个领域）：结算、仓储指令、库存 ------ 被多业务共用的能力

支撑域（3个领域）：账号、认证、基础 ------ 基础设施能力

外部防腐层（2个领域）：WMS代理、财务代理 ------ 对外交互的防腐层

实线箭头表示领域间的依赖关系

五、微服务拆分

5.1 什么是限界上下文

限界上下文（Bounded Context）是DDD中最重要的概念之一，它定义了业务的边界------在这个边界内，团队对某个领域概念有一致的、无歧义的理解。

简单来说：

每个限界上下文代表一个"语言世界"
在这个世界里，术语的含义是确定的
不同限界上下文之间通过明确的接口交互

限界上下文是微服务拆分的最小粒度：每个限界上下文对应一个或多个微服务。

5.2 服务拆分粒度：从领域到限界上下文

DDD战略设计的一个重要原则是**限界上下文（Bounded Context）**作为微服务的最小部署单元。每个限界上下文代表一个独立的业务领域，具有以下特征：

独立业务边界：领域有自己的职责范围
独立团队负责：可以由独立团队负责开发维护
独立部署：可以单独部署和升级
低耦合：领域间通过明确的接口交互

因此，服务拆分以限界上下文为最小粒度，每个领域对应一个或多个微服务。

重要说明 ：本文当前的服务拆分粒度实际上是领域（Domain） ，而非限界上下文（Bounded Context）。

为什么没有拆到限界上下文？

因素	说明
部署规模	限界上下文拆分会导致服务数量激增，运维成本大幅增加
时间约束	项目初期时间不允许进行更细粒度的领域建模
渐进演进	DDD强调演进式设计，先有整体框架，再逐步细化
团队能力	限界上下文拆分需要团队对DDD有较深理解

领域 vs 限界上下文

层次	粒度	本文实践
领域	业务范围的最大划分	✓ 完成（核心域、通用域、支撑域）
子域	领域内的业务细分	✓ 完成（如订单域下的履约子域、促销子域）
限界上下文	领域模型的边界	✗ 未完成（作为未来演进目标）

演进方向：随着业务复杂度增加和团队DDD能力提升，未来可将履约、促销等子域进一步拆分为独立的限界上下文，实现更精细的服务拆分。

5.3 服务列表

将领域设计映射为具体的微服务：

序号	工程模块	服务名称	所属领域	核心职责
1	erp-order	order	核心域-销售	销售订单全生命周期管理
2	erp-customer	customer	核心域-客户	客户/经销商档案管理
3	erp-purchasing	purchasing	核心域-采购	采购订单、供应商管理
4	erp-goods	goods	核心域-商品	商品/SKU/规格属性管理
5	erp-enterprise	enterprise	核心域-企业	多组织架构、企业主体管理
6	erp-settlement	settlement	通用域-结算	应收/收款/发票/账期管理
7	erp-warehouse-ops	warehouse-ops	通用域-仓储指令	入库单/出库单/调拨/组拆/BOM管理
8	erp-inventory	inventory	通用域-库存	ERP内部库存状态管理
9	erp-account	account	支撑域-账号	用户账号、角色、权限配置
10	erp-auth	auth	支撑域-认证	JWT签发、Token验证
11	erp-base	base	支撑域-基础	通用枚举、工具类、配置
12	erp-wms	wms-agent	外部防腐层-WMS代理	仓储指令转发与结果回传
13	erp-finance-agent	finance-agent	外部防腐层-财务代理	财务数据同步（待建）
14	cloud-gateway	gateway	网关	请求路由、限流、鉴权
15	common	common	公共	公共组件、Feign封装

5.4 服务依赖拓扑图

为了让读者直观地理解服务之间的依赖关系，这里提供完整的服务依赖拓扑图：
外部防腐层
通用域
支撑域
核心域
API网关层
外部系统
可选调用
可选调用
外部WMS系统
外部财务系统
Gateway

网关
order

订单服务
customer

客户
purchasing

采购
goods

商品
enterprise

企业
auth

认证
account

账号
base

基础
settlement

结算
warehouse-ops

仓储指令
inventory

库存
wms-agent

WMS代理
finance-agent

财务代理

图解说明：

实线箭头表示强依赖（服务A必须调用服务B才能完成业务）

虚线箭头表示弱依赖（服务A可能需要调用服务B，但不是必须的）

外部系统（WMS、财务系统）通过代理服务与内部交互，形成防腐层

5.5 服务拆分决策矩阵

为了让读者理解决策过程，这里公开我们的服务拆分决策依据。我们从不同领域类型中选取代表性服务进行说明：

5.5.1 核心域决策

考量因素	权重	Order（订单）	Customer（客户）	Purchasing（采购）	Goods（商品）
业务边界清晰度	高	✓ 独立业务流程	✓ 独立客户档案	✓ 独立采购流程	✓ 独立商品管理
团队职责独立	高	✓ 订单团队负责	✓ 客户团队负责	✓ 采购团队负责	✓ 商品团队负责
部署频率差异	高	高频（日级迭代）	中频（周级）	中频（周级）	低频（月级）
领域复杂度	高	高（状态机、促销、履约）	中（档案、信用、等级）	中（供应商、议价）	高（SKU、多维度）
外部依赖程度	低	低（内部闭环）	低	低	低
最终决策	-	独立服务	独立服务	独立服务	独立服务

核心域决策要点：核心域是业务核心竞争力，无论其他因素如何，都应独立拆分为服务。

5.5.2 通用域决策

考量因素	权重	Settlement（结算）	WarehouseOps（仓储指令）	Inventory（库存）
业务边界清晰度	高	✓ 独立财务流程	✓ 独立单据生命周期	✓ 独立库存状态
团队职责独立	中	✓ 可与财务团队共享	✓ 仓储团队负责	✓ 可共享仓储团队
部署频率差异	中	中频（与订单联动）	中频	中频
领域复杂度	高	高（财务规则复杂）	高（流程长、状态多）	中
外部依赖程度	中	中（对接财务代理）	高（依赖WMS-Agent）	高（依赖WMS）
最终决策	-	独立服务	独立服务	独立服务

通用域决策要点：结算、仓储指令、库存均是被多业务共用的能力，虽然仓储指令和库存与外部系统有关联，但它们本身是内部业务能力，通过WMS-Agent与外部系统交互，因此作为通用域独立拆分。

5.5.3 支撑域决策

考量因素	权重	Account（账号）	Auth（认证）	Base（基础）
业务边界清晰度	高	✓ 独立安全能力	✓ 独立认证能力	✓ 独立基础能力
团队职责独立	中	✓ 可合并到基础设施团队	✓ 可合并到基础设施团队	✓ 统一基础设施团队
部署频率差异	高	低频	低频	低频
领域复杂度	低	低	低	低
外部依赖程度	低	低	低	低
最终决策	-	独立服务	独立服务	独立服务

支撑域决策要点：虽然技术复杂度低，但作为基础设施需要独立演进，避免与其他业务耦合。

5.5.4 外部防腐层决策

考量因素	权重	WMS-Agent（WMS代理）	Finance-Agent（财务代理）
业务边界清晰度	高	✗ 纯转发，无业务逻辑	✗ 纯转发，无业务逻辑
团队职责独立	中	✗ 可合并到仓储	✗ 可合并到财务
部署频率差异	高	依赖外部系统	依赖外部系统
领域复杂度	低	低（仅转发）	低（仅转发）
外部依赖程度	极高	极高（直连外部）	极高（直连外部）
最终决策	-	独立服务	独立服务

外部防腐层决策要点：WMS-Agent 和 Finance-Agent 虽然技术复杂度低，但作为防腐层必须独立，以隔离外部系统变化对内部的影响。

5.5.5 决策因素说明

因素	说明
业务边界清晰度	该领域是否有独立的业务职责，不会与其他领域混淆
团队职责独立	是否有独立团队可以负责该服务的开发维护
部署频率差异	该服务是否需要比其他服务更频繁地发布
领域复杂度	业务逻辑的复杂程度（状态机、规则数量）
外部依赖程度	该服务是否需要频繁对接外部系统

六、总结与经验

6.1 实践要点回顾

DDD战略设计，经历了以下关键阶段：

阶段	核心产出	关键动作
背景调研	业务现状分析	系统盘点、痛点识别
战略设计	目标与路径	方案选型、定位决策
统一语言	术语表	术语收集、业务对齐
领域分解	领域边界	领域识别、类型划分
服务拆分	微服务清单	限界上下文映射、依赖分析

6.2 关键设计决策与经验教训

回顾整个战略设计过程，最关键的决策和经验教训总结如下：

类别	项目	说明
路径决策	建立新的标准流程	不修修补补，从源头解决问题
架构决策	代理架构	WMS代理+财务代理处理外部系统对接
架构决策	指令分离	仓储指令和财务指令分别走不同代理服务
架构决策	内外部分层	ERP内部维护指令单据，外部系统只负责执行
拆分决策	限界Context（实际为领域）	以限界上下文作为最小部署粒度
经验	业务优先	深入业务调研，技术服务于业务
经验	战略前置	战略设计阶段的充分投入，降低后续返工
经验	渐进演进	不追求一步到位，持续迭代优化
经验	共识建立	各方达成共识是推进的前提

结语

DDD战略设计是一套系统化的方法论，其核心价值在于：在动手编码之前，先把业务理解透彻、把架构规划清晰。

本文的实践经验表明：通过战略设计阶段的充分投入，能够显著降低后续战术实现的风险，让微服务拆分成为水到渠成的结果。希望能为读者提供有益的参考。