弱龄寄事外,委怀在琴书。这篇文章主要讲述全网稀缺的DDD(领域驱动设计)思想解读及落地指南相关的知识,希望能为你提供帮助。
??立即下载??
??立即下载??
?随着全行业互联网化的深入,项目所涉及的业务越来越多样、精细、专业,普通的CRUD、传统架构模式与建模方法已无法满足市场需求。在此背景下,DDD思想再次受到大厂关注与欢迎。但是,市面上很多DDD课程不够落地,大家付出大量时间还是学得云里雾里。本课程就邀请BAT资深架构师,以一个DDD研发实战为主线,带你从概念到代码,真正吃透DDD。
什么是DDD
软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前,通常需要进行大量的业务知识梳理,而后到达软件设计的层面,最后才是开发。而在业务知识梳理的过程中,我们必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计的基本概念。
听起来这和传统意义的软件开发没啥区别,只是换了点新鲜的名词而已,其实不然。
软件开发 VS DDD一般软件设计或者说软件开发分两种:??瀑布式?
?,??敏捷式?
?。
前者一般是项目经理经过大量的业务分析后,会基于现有需求整理出一个基本模型,再将结果传递给开发人员,这就是开发人员的需求文档,他们只需要照此开发便是。这种模式下,是很难频繁的从用户那里得到反馈,因此在前期分析时就已经默认了这个业务模型是正确的,那么结果可想而之,数月甚至数年后交付的时候,必然和客户的预期差距较大。
后者在此基础上进行了改进,它也需要大量的分析,范围会设计到更精细的业务模块,它是小步迭代,周期性交付,那么获取客户的反馈也就比较频繁和及时。可敏捷也不能够将业务中的方方面面都考虑到,并且敏捷是拥抱变化的,大量的需求或者业务模型变更必将带来不小的维护成本,同时,对人(Developer)的要求也必然会更高。
DDD则不同:它像是更小粒度的迭代设计,它的最小单元是??领域模型(Domain Model)?
?,所谓领域模型就是能够精确反映领域中某一知识元素的载体,这种知识的获取需要通过与??领域专家(Domain Expert)?
?进行频繁的沟通才能将专业知识转化为领域模型。领域模型无关技术,具有高度的业务抽象性,它能够精确的描述领域中的知识体系;同时它也是独立的,我们还需要学会如何让它具有表达性,让模型彼此之间建立关系,形成完整的领域架构。通常我们可以用象形图或一种??通用的语言(Ubiquitous Language)?
?去描述它们之间的关系。在此之上,我们就可以进行??领域中的代码设计(Domain Code Design)?
?。如果将软件设计比做是造一座房子,那么领域代码设计就好比是贴壁纸。前者已经将房子的蓝图框架规划好,而后者只是一个小部分的设计:如果墙纸贴错了,我们可以重来,可如果房子结构设计错了,那可就悲剧了。
建立领域知识(Build Domain Model)
说了这么多领域模型的概念,到底什么是领域模型呢?以飞机航行为例子:
现要为航空公司开发一款能够为飞机提供导航,保证无路线冲突监控软件。那我们应该从哪里开始下手呢?根据DDD的思路,我们第一步是??建立领域知识?
?:作为平时管理和维护机场飞行秩序的工作人员来说,他们自然就是这个领域的专家,我们第一个目标就是与他们沟通,也许我们并不能从中获取所有想要的知识,但至少可以筛选出主要的内容和元素。你可能会听到诸如起飞,着陆,飞行冲突,延误等领域名词,让们从一个简单的例子开始(就算是错误的也没关系):
这个模型很直接,但有点过于简单,因为我们无法看出飞机在空中做了什么,也无法得知飞机怎么从起点到的终点,刚才我们似乎提到无路线冲突,那么如此似乎会好些:
既然点构成线,那何不:
这个过程,是我们不断建立领域知识的过程,其中的重点就是寻找领域专家频繁沟通,从中提炼必要领域元素。
尽管看起来还是很简单,但我们已经开始一步步的在建立领域对象和领域模型了。
通用语言(Ubiquitous Language)
上面的例子的确看起来简单,但过程并非容易:我们(开发人员)和领域专家在沟通的过程中是存在天然屏障的:我们满脑子都是类,方法,设计模式,算法,继承,封装,多态,如何面向对象等等;这些领域专家是不懂的,他们只知道飞机故障,经纬度,航班路线等专业术语。
所以,在建立领域知识的时候,我们(开发人员和领域专家)必须要交换知识,知识的范围范围涉及领域模型的各个元素,如果一方对模型的描述令对方感到困惑,那么应该立刻换一种描述方式,直到双方都能够接受并且理解为止。在这一过程中,就需要建立一种通用语言,作为开发人员和领域专家的沟通桥梁。
可如何形成这种通用语言呢?其实答案并不唯一,确切的说也没有什么标准答案。
a)UML
利用UML可以清晰的表现类,并且展示它们之间的关系。但是一旦聚合关系复杂,UML叶子节点将会变的十分庞大,可能就没有那么直观易懂了。最重要的是,它无法精确的描述类的行为。为了弥补这种缺陷,可以为具体的行为部分补充必要说明(可以是标签或者文档),但这往往又很耗时,而且更新维护起来十分不便。
b)伪代码
极限编程是推荐这么做的,这个办法对程序猿来说固然好,可立刻就要将现有模型映射到代码层面,这对人的要求也是不低,并不容易实现。
【全网稀缺的DDD(领域驱动设计)思想解读及落地指南】?
推荐阅读
- 2021前端校招直通车,实现Offer零距离
- 笨叔(用4维空间来理解进程负载)
- HCIE-Security Day2(防火墙安全区域理解实验)
- #yyds干货盘点#Linux系统文件权限与归属
- 用于WordPress插件开发的7个精彩的工具
- 如何使用Python生成罗马风格的马赛克(代码实现)
- 如何修改Windows 10环境变量(详细图解)
- 每个开发人员都应该知道的9个方便的Git命令
- C中标识符和变量之间有什么区别()