导读
DDD 领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解 DDD 到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或帮助。
1、前言：
在当时的环境下，单体应用仍然是市场的主体，但是大型复杂软件系统已经出现，给团队的设计和开发工作带来了比较大的挑战。
DDD 提供了一种新的设计思路，通过对于业务子域和限界上下文的划分，建立跨越业务和技术的统一语言，为业务建模的同时，拉通业务和技术实现。
DDD 理论的提出，对整个软件架构设计领域，尤其是对微服务架构的设计产生了巨大的影响。那我们如何运用 DDD 来解决所面临的大型业务系统问题呢？
在这里我们以中台业务为例，进行实践和应用。
友情提示：看目录，从整体中深入内部去看
2、目前我们的现状：
2.1 软件设计所面临的挑战
•软件开发的不不确定性贯穿了了整个软件工程 的⽣生命周期。
•软件⼯程中不不可能有任何 “银弹” 解决软件 的复杂度问题。
•软件⼯程核⼼实质是社会⼯程，优秀团队 的竞争力来源于互相的信任及良好的沟通。
2.2 软件工程的复杂度：
•无法回避这种复杂性，所做的只有控制这种复杂 性。20 多年年前，顶尖的软件设计人员已经意识到
•领域建模和设计的重要性。尽管没有被清楚的表 述出来，在对象社区涌动着⼀种新的思潮，Eric Evans 把它称为领域驱动设计。
•领域驱动设计是 一种思维方式，也是一组优先任务，它旨在加速 那些必须处理理复杂领域的软件项⽬的开发。
初衷及目标：高内聚，低耦合
3、和传统架构设计相比 DDD 解决的问题
DDD 要解决的两个核心问题：
1.业务架构如何合理的设计？
2.如何使系统架构域业务架构保持一致并具备可持续的扩展？
领域驱动的设计基本目标：有效建模，并运⽤用领域模型驱动团队进⾏行行沟通分析、设计及开发。
4、领域驱设计的核心思想：
1、模型与现实业务的统一
•模型和程序设计的核心相互影响。正是模型与实现之间的紧密联系才使模型变得有⽤， 并确保我们在模型中所进行的分析能够转化为最终程序。
•模型与实现之间的这种紧密结合 在维护和后续开发期间也会很有用，因为我们可以基于对模型的理理解来解释代码。
2、统一（业务和技术）语言
•模型是团队所有成员使用的通⽤语⾔的中枢。由于模型与实现之间的关联，开发人员可 以⽤该语⾔来讨论程序。
•他们可以在无需翻译的情况下与领域专家进行沟通。⽽且由于该语言是基于模型的，因此我们可借助自然语⾔对模型本身进行精化。
3、团队的持续学习，消化知识，系统持续的发展
模型是浓缩的知识。模型是团队一致认同的领域知识的组织⽅式和重要元素的区分⽅ 式。透过我们如何选择术语、分解概念以及将概念联系起来，模型纪录了我们看待领域的⽅式。
当开发⼈员和领域专家在将信息组织为模型时，这一共同的语⾔ (模型) 能够促使 他们⾼效地协作。
4、领域驱动设计三原则
P1: Focus on your core domain.
※ 聚焦于你的 核心领域
P2: Iteratively explore models in a creative collaboration of domain practitioners and software practitioners.
※ 通过协作 迭代 探索模型
P3: Speak a Ubiquitous Language within an explicitly Bounded Context.
※ 统一语言
5、领域驱动的设计步骤：
5.1、统一语言
同一对象在不同上下文中的概念可能是不同的。
领域太复杂，只有在分割的上下文内才可能形成统一语言。
在 UML 作为建模主流的时代，软件设计被明确分为面向对象分析（OOA），面向对象设计（OOD）和面向对象编码（OOP）阶段。
实际操作中 OOD 的工作往往被 OOA 和 OOP 各自承担一部分，并同时存在分析模型和设计模型两个割裂的模型。
而领域驱动设计的核心是建立统一的领域模型。领域模型在软件架构中处于核心地位，软件开发过程中，必须以建立领域模型为中心，以保障领域模型的忠实体现。
简单理解起来的话，也就是把业务人员和开发人员的语言统一起来，用代码来感受一下大概就是：
userService.love(Jack, Rose) => Jack.love(Rose)
companyService.hire(company,employee) =>
Company.hire(employee)
5.2、领域内的事件风暴、命令风暴
领域建模的分析过程及方法：
5.2.1、 什么是领域事件？
- 捕获我们所建模的领域中所发⽣生过的事 情
“ 任何的业务事件都会以某种数据的形式 留留下⾜足迹。我们对于事件的追溯可以通过 对数据的追溯来完成。......你⽆法回到从 前去看看到底发⽣了什么，
但是却可以在 单据的基础上，⼀一定程度的还原当时事情 发⽣的场景。当我们把这些数据的⾜迹按 照时间顺序排列列起来，我们⼏乎可以清晰 的推测出这个在过往的⼀段时间内到底发 ⽣了那些事情 ”
要点：
1、业务关心的事件 ：一个领域事件必须对业务有价值，有助于形成完整的业务闭环，也即一个领域事件将导致进一步的业务操作。
2、用 “已发生” 时态描述
3、有时间顺序
5.2.2 、如何进行命令风暴？
围绕第一步识别出的领域事件， 针对各个事件进行命令分析。 什么样的命令导致的这个事件的发生。
有的命令可能产生多个事件，可以使用箭头将它们连接
5.2.3、 寻找聚合
5.2.3.1 什么是聚合
持续探索
在领域驱动设计中，聚合是⼀一组相关领 域对象，其⽬目的是要确保业务规则在领 域对象的各个⽣命周期都得以执行:
‣ 聚合边界内保证业务不不变性 (invariant)
‣ 只能通过聚合根修改边界内的对象
‣ 聚合根有全局标识
5.2.4、 持续探索：
领域驱动开发强调维护应⽤程序模型的概 念完整性。但如果不不对模型的概念完整性 进行妥协的话，传统的 DDD ⽅法不能盲目 地应用在⼀个⽆限大的领域模型中。
真正 让模型得以最大程度地扩展，并且不不必牺 牲其概念完整性的⽅法叫做 “上下⽂文”。限界上下文明确地定义模型所应⽤的上下文。根据团队的组织、软件系统的各个部
分的⽤法以及物理理表现 (代码和数据库模 式等) 来设置模型的边界。在这些边界中 严格保持模型的⼀致性，⽽不要受到边界 之外问题的干扰和混淆。
通过定义不同上下文之间的关系，中创建的一个所有模型上下文的全局视图。
6、DDD 领域设计的服务划分
6.1 修缮模式（遗留系统重构）
“修缮者模式” 在既有系统资产的基础上，通过剥离新业务和功能，逐步 “释放” 现有系统耦合度，解决遗留系统质量不稳定和 Bug 多的 问题。实现传统 IT 性能提升，⾯对传统的 IT 业务更加稳定灵活，降低维护成本。
‣修缮模式适⽤于需求变更频率不高的存量系统
6.2 绞杀模式（遗留系统重构）
绞杀者模式” 在既有系统资产的基础上实现数字 IT 创新，⾯对创新的数字 IT 业务更加灵活。 ‣通过在新的应用中实现新特性，保持和现有系统的松耦合，仅在必要时将功能从原系统中剥离，以此逐步地替换原有系统。
目前中台对电销系统已采用绞杀模式，进行重构。
6.3 服务划分原则
依据业务限界上下⽂文边界划分
‣ 在业务层面实现了高内聚和低耦合‣ 在颗粒度上是⽐较适应刚开始做服务化架构的团队能力的
‣按照组织结构划分‣ 依照康威定律来划分服务
‣对于技术能⼒相对⽐比较成熟的团队，可以依据识别出来的聚合关系拆分 服务
在实操过程中，不不同组织也在应⽤用以下服务划分原则
‣按照变更的频率拆分‣ 可以按照系统功能中不同的变更频率来划分服务，通常
来说，越靠近终端⽤户的特性变更频率越高，反之越低
‣按照技术异构的边界划分‣ 按照不同的技术选型发展方向来划分系统
‣按照业务对于伸缩性或者健壮性的不同要求划分 ‣按照企业对于安全性的不同要求划分
7、DDD 全景图
1、战略设计
战略设计会控制和分解战术设计的边界与粒度，战术设计则以实证角度验证领域模型的有效性、完整性与一致性，进而以演进的方式对之前的战略设计阶段进行迭代，从而形成一种螺旋式上升的迭代设计过程，如下图所示：
2 战术设计
3、全景视图操作流程
两个不同阶段的设计目标是保持一致的，它们是一个连贯的过程，彼此之间又相互指导与规范，并最终保证一个有效的领域模型和一个富有表达力的实现同时演进。
8、领域模型
DDD 革命性在于：领域模型准确反映了业务语言，而传统 J2EE 或 Spring+Hibernate 等事务性编程模型只关心数据，这些数据对象除了简单 setter/getter 方法外，没有任何业务方法，被比喻成失血模型。
那模型都有几种，他们的区别是什么？ 我们该怎么选择？（题外话：各有优劣，大家需要找到自己期望的平衡点，不要盲目的使用任何一种。）
1、模型分类及特征
•失血模型：模型仅仅包含数据的定义和 getter/setter 方法，业务逻辑和应用逻辑都放到服务层中。这种类在 Java 中叫 POJO，在.NET 中叫 POCO。
•贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。
•充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是 UI 层->服务层->领域层↔持久层。
•胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。
2、对 4 种模型的理解
在基于贫血模型的传统开发模式中，Service 层包含 Service 类和 BO 类两部分，BO 是贫血模型，只包含数据，不包含具体的业务逻辑。业务逻辑集中在 Service 类中。在基于充血模型的 DDD 开发模式中，
Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。而 Service 类变得非常单薄。
总结一下的话就是，基于贫血模型的传统的开发模式，重 Service 轻 BO；基于充血模型的 DDD 开发模式，轻 Service 重 Domain。
•贫血模型优缺点：
这种模型的优点： 1、各层单向依赖，结构清楚，易于实现和维护 2、设计简单易行，底层模型非常稳定 这种模型的缺点： 1、domain object 的部分比较紧密依赖的持久化 domain logic 被分离到 Service 层，显得不够 OO 2、Service 层过于厚重
•充血模型优缺点：
这种模型的优点： 1、更加符合 OO 的原则 2、Service 层很薄，只充当 Facade 的角色，不和 DAO 打交道。 这种模型的缺点： 1、DAO 和 domain object 形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。
2、如何划分 Service 层逻辑和 domain 层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。 3、考虑到 Service 层的事务封装特性，Service 层必须对所有的 domain object 的逻辑提供相应的事务封装方法，其结果就是 Service 完全重定义一遍所有的 domain logic，非常烦琐，而且 Service 的事务化封装其意义就等于把 OO 的 domain logic 转换为过程的 Service TransactionScript。该充血模型辛辛苦苦在 domain 层实现的 OO 在 Service 层又变成了过程式，
对于 Web 层程序员的角度来看，和贫血模型没有什么区别了。
1.事务我是不希望由 Item 管理的，而是由容器或更高一层的业务类来管理。
2.如果 Item 不脱离持久层的管理，如 JDO 的 pm，那么 itemDao.update(this); 是不需要的，也就是说 Item 是在事务过程中从数据库拿出来的，并且声明周期不超出当前事务的范围。
3.如果 Item 是脱离持久层，也就是在 Item 的生命周期超出了事务的范围，那就要必须显示调用 update 或 attach 之类的持久化方法的，这种时候就应该是按 robbin 所说的第 2 种模型来做。
胀血模型优缺点：
该模型优点： 1、简化了分层 2、也算符合 OO 该模型缺点： 1、很多不是 domain logic 的 service 逻辑也被强行放入 domain object ，引起了 domain ojbect 模型的不稳定 2、domain object 暴露给 web 层过多的信息，可能引起意想不到的副作用。
评价：
在这四种模型当中，失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说，都已经是可行的了。
第一种模型绝大多数人都反对，因此反对理由我也不多讲了。但遗憾的是，我观察到的实际情形是，很多使用 Hibernate 的公司最后都是这种模型，
这里面有很大的原因是很多公司的技术水平没有达到这种层次，所以导致了这种贫血模型的出现。从这一点来说，Martin Fowler 的批评声音不是太响了，而是太弱了，还需要再继续呐喊。
第二种模型就是 Martin Fowler 一直主张的模型，实际上也是我们一直在实际项目中采用这种模型。不过我觉得这种模型仍然不够完美，因为你还是需要一个业务逻辑层来封装所有的 domain logic，这显得非常罗嗦，
并且业务逻辑对象的接口也不够稳定。如果不考虑业务逻辑对象的重用性的话 (业务逻辑对象的可重用性也不可能好)，很多人干脆就去掉了 xxxManager 这一层，在 Web 层的 Action 代码直接调用 xxxDao，
同时容器事务管理配置到 Action 这一层上来。Hibernate 的 caveatemptor 就是这样架构的一个典型应用。
第三种模型是我很反对的一种模型，这种模型下面，Domain Object 和 DAO 形成了双向依赖关系，无法脱离框架测试，并且业务逻辑层的服务也和持久层对象的状态耦合到了一起，会造成程序的高度的复杂性，
很差的灵活性和糟糕的可维护性。也许将来技术进步导致的 O/R Mapping 管理下的 domain object 发展到足够的动态持久透明化的话，这种模型才会成为一个理想的选择。
就像 O/R Mapping 的流行使得第二种模型成为了可能 Martin Fowler 的 Domain Model，或者说我们的第二种模型难道是完美无缺的吗？当然不是，接下来我就要分析一下它的不足，以及可能的解决办法。
（详细代码示例及解析请参阅：https://my.oschina.net/u/1999167/blog/1841997 ）
3、为什么基于贫血模型的传统开发模式如此受欢迎？
前面我们讲过，基于贫血模型的传统开发模式，将数据与业务逻辑分离，违反了 OOP 的封装特性，实际上是一种面向过程的编程风格。
但是，现在几乎所有的 Web 项目，都是基于这种贫血模型的开发模式，甚至连 Java Spring 框架的官方 demo，都是按照这种开发模式来编写的。
4、 DDD 完全的充血或者胀血模型得与失
在聊到 DDD 的时候，我经常会做一个假设：假设你的机器内存无限大，永远不宕机，在这个前提假设下，我们是不需要持久化数据的，也就是我们可以不需要数据库，
那么你将会怎么设计你的软件？这就是我们说的 Persistence Ignorance：持久化无关设计。没了数据库，领域模型就要基于程序本身来设计了，热爱设计模式的同学们可以在这里大显身手。在面向过程，面向函数，面向对象的编程语言中，面向对象无疑是领域建模最佳方式。
类与表有点像（不少人认为表和类就是对应的，行 row 和对象 object 就是对应的），我个人强烈地不认同这种等同关系，这种认知直接导致了软件设计变得没有意义。类和表有以下几个显著区别，
这些区别对领域建模的表达丰富度有显著的差别，有了封装、继承、多态，我们对领域模型的表达要生动得多，对 SOLID 原则的遵守也会严谨很多。
由于不再承载领域建模这个特性，数据库的设计可以变得天马行空，任何可以加速存储和搜索的手段都可以用上，我们可以用 column 数据库，可以用 document 数据库，
可以设计非常精巧的中间表去完成大数据的查询。总之数据库设计要做的事情就是尽可能的高效存取，而不是完美表达领域模型（此言论有点反动，大家看看就好），这样我们再看看架构图：
所以：理想很丰满，现实很骨感。我们并不能有无限大的内存。 在实际应用中我们一定是要避免模型的胀血。不然会带来很大的麻烦。
9、领域驱动在中台业务分析中的实践
1 、业务中台 DDD 领域 应用架构规范
2 、 业务中台使用 DDD 领域建模的愿景（架构分层）
3 、现有系统使用 DDD 进行领域分析
4、 数据结构模型边界的构建
个人总结：DDD 只是一种方法论，网上各种公司的 DDD 框架，也只是对方法论按照自己的理解进行的一种实践和实验。 所以不要纠结于什么才是一个 DDD 框架，怎么写一个 DDD 框架。
更不要死板的去套 DDD 的各种充血贫血模型， 找到适合自己的模型，解决建模问题才是最重要的。 DDD 只是为你提供了一套系统的方法论仅此而已，并没有多高大上。
推荐教程与文档：
板桥大话 DDD 用大白话简单谈谈 DDD 的一些基础特点，只是扫盲！数据库 SQL 强人慎入
板桥 DDD 研究十年心得：《复杂软件设计之道：领域驱动设计全面解析与实战》 承蒙机械出版社厚爱
板桥：为什么 DDD 的 Bounded Context 翻译为"有界上下文"？
业务代码编程陷阱案例 - jaxenter 非常普遍的不恰当的编程方式，失血模型导致的陷阱
面向对象建模与数据库建模两种分析设计方法的比较 数据库驱动设计与对象建模是决定软件不同命运的两大派别，谁可以让软件更具有生命，维护拓展更方便？伸缩性更强?
鲍勃大爷：先设计对象的行为，再设计数据库表结构！ 软件工程大师、敏捷创建者之一鲍勃大叔的建议
面向对象与领域建模 据调查，目前有 70% 左右程序员是在使用 OO 语言编写传统过程化软件，缺乏完整的面向对象思维方法的教育和培训是基本根源，本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点
Evans DDD 领域建模 如何提炼模型，而不是数据表，进而精化模型对象，使其能够反映领域概念基本本质是一个复杂过程，Evans DDD 是 2004 年提出的具备革命性影响的软件思想。
实战 DDD(Evans DDD:Domain-Driven Design 领域驱动设计) 领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。
如何从职责和协作中发现丰富的充血对象？失血模型贫血模型是 DDD 最大敌人，如何根据SOLID 原则和GRASP 原则设计业务行为？本文给出了 DDD 具体实践中一些具体细节，是和 DDD 配合一起进行面向对象分析设计的好方法。
业务模型统一描述 统一语言是 DDD 一个重要特征和重点。
DDD CQRS 和 Event Sourcing 的案例：足球比赛 DDD + CQRS + Event Sourcing 实现案例，结合代码与理论讲解。
集装箱车队系统的 DDD 案例 为上海某大型港口公司的运输系统实施的一个领域驱动设计 DDD 的实战咨询案例。
使用 DDD 聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现
向领域驱动设计前进： 如何使用 DDD 实现从单体到微服务迁移打造业务平台或中台？
DDD+ 微服务大型案例：Uber 如何从复杂的 RPC 微服务转向面向业务领域的微服务架构 DOMA？
全球大型电商 Shopify 如何使用 DDD 实现单体架构的模块化？
参考博客文献：（吃水不忘挖井人）
•浅谈 MVC、MVP 和 MVVM 架构模式：https://draveness.me/mvx
•上善若水的博客：http://deshui.wang/
•CRUD 工程师晋级之路：https://zhuanlan.zhihu.com/p/25442175
•对象和数据库的天然阻抗：https://www.jdon.com/mda/oo-reltaion2.html
•Commands & Events instead of CRUD — Part 1: Commands：https://hackernoon.com/commands-events-instead-of-crud-part-1-commands-17f4c7aee33b
•汤雪华的博客：https://www.cnblogs.com/netfocus/
•There is No U in CRUD：http://jlhood.com/there-is-no-u-in-crud/
•Event sourcing vs CRUD：https://community.risingstack.com/event-sourcing-vs-crud/
•阿里盒马领域驱动设计实践：https://www.infoq.cn/article/alibaba-freshhema-ddd-practice
•DDD 战略篇：架构设计的响应力：https://zhuanlan.zhihu.com/p/30878497
•使用 DDD 来构建你的 REST API，而不是 CRUD：http://blog.didispace.com/use-ddd-design-rest-api/
•DDD & co., part 1: What's wrong with CRUD：https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/
•DDD 的终极大招——By Experience：https://insights.thoughtworks.cn/ddd-by-experience/
•领域驱动设计概览：http://zhangyi.xyz/overview-of-ddd/
•Refactoring from anemic model to DDD：https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f
•为什么 DDD 是设计微服务的最佳实践：https://www.jianshu.com/p/e1b32a5ee91c
•领域驱动设计在互联网业务开发中的实践：https://kb.cnblogs.com/page/586236/
•领域驱动设计 (DDD:Domain-Driven Design) https://www.jdon.com/ddd.html
•#DDD 仓储模式 #DDD Specification 规格模式
•# 领域事件 #EventStorming #CQRS 架构
作者：京东科技 黄学斌
来源：京东云开发者社区