文章目录
- [DDD 架构是什么：工业制造场景下的领域驱动设计](#DDD 架构是什么：工业制造场景下的领域驱动设计)
-
- [一、DDD 的核心目标](#一、DDD 的核心目标)
- [二、DDD 的几个核心概念](#二、DDD 的几个核心概念)
-
- [1. 领域（Domain）](#1. 领域（Domain）)
- [2. 限界上下文（Bounded Context）](#2. 限界上下文（Bounded Context）)
- [3. 实体（Entity）](#3. 实体（Entity）)
- [4. 值对象（Value Object）](#4. 值对象（Value Object）)
- [5. 聚合（Aggregate）](#5. 聚合（Aggregate）)
- [6. 领域服务（Domain Service）](#6. 领域服务（Domain Service）)
- [7. 领域事件（Domain Event）](#7. 领域事件（Domain Event）)
- [三、DDD 在工业制造里为什么有价值](#三、DDD 在工业制造里为什么有价值)
-
- [1. 业务语义复杂](#1. 业务语义复杂)
- [2. 长期演进明显](#2. 长期演进明显)
- [3. 多团队协作明显](#3. 多团队协作明显)
- [4. 追溯和一致性要求高](#4. 追溯和一致性要求高)
- [四、DDD 和 AAA 的关系](#四、DDD 和 AAA 的关系)
-
- [AAA 更偏结构](#AAA 更偏结构)
- [DDD 更偏建模](#DDD 更偏建模)
- [五、一个工业制造例子：报工场景中的 DDD](#五、一个工业制造例子：报工场景中的 DDD)
-
- [1. 实体](#1. 实体)
- [2. 值对象](#2. 值对象)
- [3. 领域服务](#3. 领域服务)
- [4. 领域事件](#4. 领域事件)
- [5. 聚合](#5. 聚合)
- [六、DDD 的优点](#六、DDD 的优点)
-
- [1. 业务表达力强](#1. 业务表达力强)
- [2. 规则集中](#2. 规则集中)
- [3. 更适合复杂系统演进](#3. 更适合复杂系统演进)
- [4. 便于拆分边界](#4. 便于拆分边界)
- [七、DDD 的缺点](#七、DDD 的缺点)
-
- [1. 学习成本高](#1. 学习成本高)
- [2. 容易过度设计](#2. 容易过度设计)
- [3. 对业务理解要求高](#3. 对业务理解要求高)
- [4. 落地需要纪律](#4. 落地需要纪律)
- [八、工业制造里怎么避免把 DDD 用重](#八、工业制造里怎么避免把 DDD 用重)
-
- [1. 只在核心域使用 DDD](#1. 只在核心域使用 DDD)
- [2. 先划边界，再建模型](#2. 先划边界，再建模型)
- [3. 模型要服务业务，不要服务术语](#3. 模型要服务业务，不要服务术语)
- [4. 不要强行全系统 DDD 化](#4. 不要强行全系统 DDD 化)
- 九、一个简短结论
DDD 架构是什么：工业制造场景下的领域驱动设计
DDD 是 Domain-Driven Design ，中文通常译为 领域驱动设计 。
它不是一种固定的代码模板，而是一套围绕业务领域建模的方法论。
如果说 AAA 更关注系统怎么分层、怎么接入、怎么隔离复杂性，
那么 DDD 更关注的是：
- 业务到底怎么理解
- 核心概念怎么命名
- 规则应该放在哪里
- 系统边界怎么划
- 不同业务模块之间怎么协作
在工业制造领域，DDD 特别常见，因为制造业的复杂性往往不在页面，而在业务语义本身。
一、DDD 的核心目标
DDD 解决的不是"代码怎么写最省事"，而是：
让软件模型尽量贴近真实业务模型。
也就是说，系统里定义的对象、行为、状态、规则，应该尽可能和业务人员、工艺人员、现场人员对同一件事的理解一致。
比如在制造系统里：
- "工单"不是一个随便的记录表
- "报工"不是一个普通提交动作
- "批次"不是一个字符串字段
- "设备状态"不是几个枚举值
它们背后都有明确的业务语义和约束。
DDD 就是要把这些语义沉淀成模型。
二、DDD 的几个核心概念
1. 领域（Domain）
领域就是你要解决的业务问题空间。
在工业制造里，领域可能包括：
- 生产执行
- 设备管理
- 质量管理
- 物料追溯
- 工艺管理
- 仓储协同
2. 限界上下文（Bounded Context）
这是 DDD 非常重要的概念。
同一个词，在不同业务边界里可能含义不同。
限界上下文就是把这些语义边界划清楚。
例如：
- 在 ERP 里，"完工"偏成本与库存结算
- 在 MES 里，"完工"偏生产流程结束
- 在 WMS 里，"完工"可能关联入库动作
如果不划边界，这些概念很容易混在一起。
3. 实体（Entity）
实体是有唯一标识、会持续变化的对象。
例如：
- 工单
- 设备
- 批次
- 检验单
它们的属性会变，但身份是稳定的。
4. 值对象（Value Object）
值对象没有独立身份，主要看值本身。
例如：
- 温度
- 产量
- 工艺参数
- 坐标
- 时间区间
值对象适合表达稳定的业务属性。
5. 聚合（Aggregate）
聚合是把一组相关对象组织成一个一致性边界。
比如一个"工单聚合"里，可能包括：
- 工单主信息
- 工序执行信息
- 当前状态
- 报工记录摘要
对外只通过聚合根修改，保证业务一致性。
6. 领域服务（Domain Service）
如果某些业务规则不适合放在实体里，就可以放到领域服务里。
例如：
- 计算是否允许开工
- 判断工序切换是否合法
- 计算良率
- 判定质量放行
7. 领域事件（Domain Event）
领域中的重要状态变化，可以以事件形式表达。
例如：
- 工单已开工
- 报工已完成
- 设备告警已触发
- 检验未通过
这在工业系统里非常有用，因为很多联动都是基于事件发生的。
三、DDD 在工业制造里为什么有价值
工业制造的特点决定了它很适合 DDD：
1. 业务语义复杂
同样是"完工""报工""暂停"，在不同工厂、不同工艺、不同系统里含义都可能不同。
2. 长期演进明显
制造系统通常不是一次性交付，而是持续迭代很多年。
DDD 有利于让模型长期保持可维护性。
3. 多团队协作明显
业务、工艺、设备、IT、集成团队经常都在同一个系统上协作。
DDD 能帮助统一语言。
4. 追溯和一致性要求高
制造业对状态一致性、过程追溯、质量闭环要求很高。
DDD 的聚合、事件、边界管理很适合这些场景。
四、DDD 和 AAA 的关系
这两个概念经常一起出现，但它们不是一回事。
AAA 更偏结构
它解决的是：
- 应用层怎么组织
- 领域层怎么沉淀
- 接入层怎么隔离
DDD 更偏建模
它解决的是：
- 业务对象怎么定义
- 规则怎么表达
- 边界怎么划分
- 语言怎么统一
简单说：
- AAA 是架构骨架
- DDD 是业务建模方法
工业项目里常见的做法是：
用 AAA 做外部结构，用 DDD 做核心业务建模。
五、一个工业制造例子：报工场景中的 DDD
以"工单报工"为例，DDD 会怎么建模？
1. 实体
WorkOrderOperationProductionExecutionInspectionOrder
2. 值对象
QuantityWorkTimeRangeOperationCodeDeviceState
3. 领域服务
WorkOrderExecutionServiceQualityDecisionService
4. 领域事件
WorkReportedEventOperationCompletedEventInspectionFailedEvent
5. 聚合
- 以
WorkOrder作为聚合根，管理工序流转和报工状态
这样做的好处是：
不是简单把表结构搬进代码，而是把制造业务的规则表达清楚。
六、DDD 的优点
1. 业务表达力强
模型更贴近现场语言，沟通成本低。
2. 规则集中
复杂规则不会散落在 Controller、SQL、工具类里。
3. 更适合复杂系统演进
随着业务增长，模型能更稳地扩展。
4. 便于拆分边界
适合多团队协作和系统拆分。
七、DDD 的缺点
1. 学习成本高
实体、值对象、聚合、限界上下文这些概念，不是所有团队都能快速掌握。
2. 容易过度设计
很多项目会把 DDD 当成"必做模板"，结果引入大量复杂对象和抽象。
3. 对业务理解要求高
如果连业务流程都没搞清楚，DDD 很容易建模失败。
4. 落地需要纪律
命名、边界、依赖方向、测试策略都要持续治理。
八、工业制造里怎么避免把 DDD 用重
1. 只在核心域使用 DDD
比如：
- 报工
- 质量判定
- 工单流转
- 批次追溯
- 设备状态联动
这些适合深度建模。
而像字典配置、基础资料、简单查询，不一定需要完整 DDD。
2. 先划边界，再建模型
不要先画一堆类图。
先把业务边界、职责、上下游关系搞清楚。
3. 模型要服务业务，不要服务术语
有些团队会过度追求"像 DDD 书上的名词"，但业务人员听不懂。
真正重要的是模型能否准确表达业务。
4. 不要强行全系统 DDD 化
一个项目里，核心域可以重一点，外围模块可以轻一点。
这通常是最现实的做法。
九、一个简短结论
如果用一句话概括 DDD：
DDD 是把软件系统建立在业务领域理解之上的设计方法。
在工业制造场景里，它特别适合处理那些：
- 规则复杂
- 语义多变
- 需要长期维护
- 需要跨系统协同
的核心业务模块。