1、前言：

在当时的环境下，单体应用仍然是市场的主体，但是大型复杂软件系统已经出现，给团队的设计和开发工作带来了比较大的挑战。

DDD提供了一种新的设计思路，通过对于业务子域和限界上下文的划分，建立跨越业务和技术的统一语言，为业务建模的同时，拉通业务和技术实现。

DDD理论的提出，对整个软件架构设计领域，尤其是对微服务架构的设计产生了巨大的影响。那我们如何运用DDD来解决所面临的大型业务系统问题呢？

在这里我们以中台业务为例，进行实践和应用。

友情提示：看目录，从整体中深入内部去看

2、目前我们的现状：

2.1软件设计所面临的挑战

•软件开发的不不确定性贯穿了了整个软件工程的⽣生命周期。
•软件⼯程中不不可能有任何“银弹”解决软件的复杂度问题。
•软件⼯程核⼼实质是社会⼯程，优秀团队的竞争力来源于互相的信任及良好的沟通。

2.2软件工程的复杂度：

无法回避这种复杂性，所做的只有控制这种复杂性。20多年年前，顶尖的软件设计人员已经意识到
领域建模和设计的重要性。尽管没有被清楚的表述出来，在对象社区涌动着⼀种新的思潮，Eric Evans把它称为领域驱动设计。
领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理理复杂领域的软件项⽬的开发。

初衷及目标：高内聚，低耦合

3、和传统架构设计相比DDD解决的问题

DDD要解决的两个核心问题：

业务架构如何合理的设计？
如何使系统架构域业务架构保持一致并具备可持续的扩展？

领域驱动的设计基本目标：有效建模，并运⽤用领域模型驱动团队进⾏行行沟通分析、设计及开发。

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、数据结构模型边界的构建

参考博客文献：（吃水不忘挖井人）

浅谈 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有界上下文 #DDD聚合
#DDD实体 #DDD值对象 #DDD服务
#DDD仓储模式 #DDD Specification规格模式
#领域事件 #EventStorming #CQRS架构

【实践篇】最全的【DDD领域建模】小白学习手册（文末附资料）