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

导读

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翻译为"有界上下文"?

板桥:DDD中问题空间和解决方案空间是一个伪命题

业务代码编程陷阱案例 - jaxenter 非常普遍的不恰当的编程方式,失血模型导致的陷阱

面向对象建模与数据库建模两种分析设计方法的比较 数据库驱动设计与对象建模是决定软件不同命运的两大派别,谁可以让软件更具有生命,维护拓展更方便?伸缩性更强?

鲍勃大爷:先设计对象的行为,再设计数据库表结构! 软件工程大师、敏捷创建者之一鲍勃大叔的建议

面向对象与领域建模 据调查,目前有70%左右程序员是在使用OO语言编写传统过程化软件,缺乏完整的面向对象思维方法的教育和培训是基本根源,本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点

Evans DDD 领域建模 如何提炼模型,而不是数据表,进而精化模型对象,使其能够反映领域概念基本本质是一个复杂过程,Evans DDD是2004年提出的具备革命性影响的软件思想。

实战DDD(Evans DDD:Domain-Driven Design领域驱动设计) 领域建模是一种艺术的技术,不是数学的技术,它是用来解决复杂软件快速应付变化的解决之道。

领域模型驱动设计(Evans DDD)之模型提炼

软件建模设计

如何从职责和协作中发现丰富的充血对象?失血模型贫血模型是DDD最大敌人,如何根据SOLID原则GRASP原则设计业务行为?本文给出了DDD具体实践中一些具体细节,是和DDD配合一起进行面向对象分析设计的好方法。

业务模型统一描述 统一语言是DDD一个重要特征和重点。

DDD CQRS和Event Sourcing的案例:足球比赛 DDD + CQRS + Event Sourcing实现案例,结合代码与理论讲解。

集装箱车队系统的DDD案例 为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。

DDD仓储实现:Spring Data JDBC教程

不使用DDD的后果:为什么我们停止了向微服务的迁移?

使用DDD聚合发现隐藏的业务规则的案例分析:数据库事务的业务实现

向领域驱动设计前进: 如何使用DDD实现从单体到微服务迁移打造业务平台或中台?

DDD+微服务大型案例:Uber如何从复杂的RPC微服务转向面向业务领域的微服务架构DOMA?

全球大型电商Shopify如何使用DDD实现单体架构的模块化?

更多#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有界上下文 #DDD聚合

#DDD实体 #DDD值对象 #DDD服务

#DDD仓储模式 #DDD Specification规格模式

#领域事件 #EventStorming #CQRS架构

作者:京东科技 黄学斌

来源:京东云开发者社区

热门相关:洪荒二郎传   爱欲不眠夜2   闺范   神算大小姐   大妆