一、简介
领域驱动相信都不陌生,个人觉得是一个非常好的软件开发思想,帮助我们充分发挥面向对象的思想,同时让设计模式发挥他的魔力,同时让我们的代码不再局限于过程式的脚本.所以,打算写一个系列的关于领域驱动设计的随笔,来提升自己的架构能力.本系列的随笔参考于领域驱动设计：软件核心复杂性应对之道这本书,我会对上面的内容做一个整理归纳,从C#程序员的角度,去总结一些观点。废话不多说,here wo go!
二、基本知识点
1、什么是领域
日常开发种我们的软件都是为了满足用户的需求,或者说帮助他们解决某一类的问题。所以这个时候用户下载我们设计的软件,并把他们应用于某个主题区域,比如说网易云音乐,解决的就是用户在线听歌的问题,所以用户自然会把他归结到在线音乐的主题区域, 此时,根据领域驱动设计的理念,这个主题区域就是领域.
2、领域的应用范围
领域的范围应用很广,归纳之,主要包含物质世界和虚拟世界,如一个点餐程序,他的领域包含餐厅和收银员等,这一类的都涉及物质世界。再如一个代码管理工具,他的领域则是代码,这一类涉及虚拟的世界.
3、传统开发模式的问题,以及领域模型的诞生
为了构建一个某个领域高价值的软件,开发团队不得不去研究该领域下的所有知识,所需的知识是非常庞大的.而且复杂程度也非常的高,所以这个时候引入领域模型是非常必要的,因为领域模型对所有的知识进行有选择的简化和结构化,帮助我们识别出领域种的核心关键点.通过领域模型能帮助我们有效的消化知识,让知识看起来很流畅,而不是像传统文档那样,一团乱麻!
4、领域模型的概念和作用
领域模型不单单是一个模型图,而是一种思想,是一种经过严格组织并精心选择的抽象知识,直击领域的核心.忽略掉领域的部分细节.模型图可以表达一种模型,作为程序员,一段好的代码也可以,好的文档也可以.所以知识选择得当领域模型可以是任何知识的载体,单前提是该载体必须是经过严格组织并精心选择的抽象知识.
重点:
建立领域模型并非原封不动建立一个符合"现实"的模型,这是不可能的,如果让你开发一个关于生活的软件,你可能将生活种的每个细节都通过代码展现出来,即使强如BAT,也做不到.所以建立领域模型更像是拍一部纪录片,将生活中最美好的部分展现给观众,软件也是如此,通过建模将软件和核心点抽象出来(形成领域模型),然后将所有的模型通过算法连接起来,写成软件给用户使用.
5、领域模型在领域驱动设计中的作用
(1)、模型和设计的相互影响
我们通过对领域知识的抽象形成一个个领域模型,此时的模型和实现是紧密结合的,如果通过代码将模型转换成一个有用的产品,那么此时后续的开发人员就能通过模型很好的理解代码为什么要这样实现.而不用通过沟通或者查看复杂的文档去理解.而且后续的修改扩展也很方便,只需围绕这个模型即可.通过对模型的把控,就能验证后续的需求实现的可能性,以及当前的模型存在的一些问题等等.
(2)、模型的重要性
一旦业务形成可用的领域模型,那么他就会变成团队的交流的中枢,后续的修改,团队都会围绕该模型展开.这时候模型就变成了一种交流的语言.所以,后续我们就可以通过语言来对他进一步的扩展.这是我们天生就具有的本领.
三、消化知识
1、如何构建最初的模型
关于消化知识,其实就是抽象领域知识的过程,这里举个列子,假设需要设计一个.Net用户登陆系统,这里假设我之前没有做过相关的功能,这个时候恰好有一个领域专家配合我.那么下面我们就开始进行头脑风暴.开始我想让专家告诉我想通过C#代码达成什么。但是他完全没有C#编码经验.刚开始很艰难,但是我们得到了最基本的两个元素如下:
接着我们继续讨论,他告诉我,用户必须输入用户名和密码才能登陆系统!而且用户必须注册到服务器,然后登陆的时候验证用户名和密码服务器中时候存在,存在则登陆成功,才能访问服务器上的资源.所以我修改了模型如下:
接着我们继续讨论,他告诉要加一个验证码和限制登陆次数为5次的功能,防止机器程序强行登陆.所以我继续修改模型,这里就不加图了.
就这样,我们继续讨论,随着我对领域知识加深,不断的修改模型,最终形成了初期的领域模型,如下:
这个时候,如果专家提出了新的需求,我就判断当前模型是否能满足他提出的需求,如果不满足,就修改模型。在精华模型的同时,代码也随之演进.最终形成了一个高扩展高可用的用户登陆模块.
2、有效建模的要素
(1)、模型和实现的绑定
上面的模型图和实现深度绑定虽然很简陋,但他在模型和实现之间建立了早期的链接,而且在后续的迭代中我们将一直维护该原型.
(2)、获得了一种基于模型的语言
最初,专家不得不向我解释用户登陆领域的问题,而我也必须向他解释C#类的概念,随着模块的扩展,我们都能使用模型中的术语,并将他们组织为符合模型的语句.那么后续的开发中我们就不需要解释各自领域的专业术语.
(3)、提炼模型
在模型日趋完善的过程中,重要的概念不断地被加到模型中,不重要地概念则被剔除.当一个不需要的概念和一个需要的概念产生关联式,则将需要的概念提取到一个新的模型中,不需要的删除掉.
(4)、头脑风暴的重要性
语言和操作,加上头脑风暴,使我们的模型茁壮的生长,当团队走查场景时,口头表达就可以测试模型的有效性,在这个过程中,基于模型的语言提供了很大的帮助,能帮助我们不断地训练模型,检测模型地可用性,以及一段地扩展模型,最后我们将得到一个很有价值的模型.
3、传统瀑布方法的缺点
传统瀑布方法,业务专家和分析员对业务进行分析,并形成抽象并传递给程序员,这个过程分析员全权负责创建模型,这个模型只是参考业务专家的意见,并没有让程序员参与,这样久而久之,只有业务专家和分析员精通业务知识,知识只是朝一个方向流动,没有形成积累.如果这个过程让程序员参与,那么好的程序员,自然而然会开发出一个可以完成更多工作的模型.
但是如果这个过程只让程序员参与,那么得出得模型是非常幼稚得.所以如果这个过程如果让两者都参与到其中,那么得出得模型是非常优质得.所以这就是领域驱动得优势.
