领域驱动设计之我见-面向对象思维

领域驱动设计之我见-面向对象思维

公司最近在推动研发体系员工技能图谱学习,其中对技术经理有一项基本要求是领域建模能力。关于领域驱动设计,埃文斯前辈出版过一本书《领域驱动设计:软件核心复杂性应对之道》,想必大多软件工程师都有读过,也对领域驱动设计有不同的见解,我的理解领域建模也就是面向对象建模。

我本身并非科班出身,原本是个地道的Giser,大学期间学的第一门语言是C语言,继而又学习了C++,也曾从事过几年的C++开发工作。入门学习C语言时,感觉计算机语言就是对大脑思维的一种抽象,像数学的计算公式一样,将思维符号化,然后使用符号计算代替人脑的推理。当开始学习C++时,感觉进入了一种全新的状态,我开始使用计算机语言模拟这个世界,使用类来模拟一个看得见摸得着的实体,而不在是C语言那样简单的将一串思维符号化了。这种编程思维反过来影响现实世界的看待问题的方式,当我面对复杂问题时,如何根据问题的上下文对问题进行归类,划分属性,理清所属关系,进而理出一个可行的方案,一步一步解决问题。

最开始做软件设计是一个课堂作业,做一个使用MFC开发一款CAD软件。设计思路很简单:定义一个基类graphic,然后派生出line、arc、rect分别代表线、弧、多边形;再定义一个基类graphicStyle,然后派生对应的style;最后通过MFC的document捕获鼠标输入,并绘制相应的图案。如下:

领域驱动设计之我见-面向对象思维_第1张图片

如上是一个典型的面向对象的设计方案,将现实世界的点线面抽象为计算语言中的一个个类,每个类包含自己的属性数据和方法。

然而,做了几年C++之后在一个不巧的机会,开始转做Java开发,进入互联网软件领域,虽然Java语言相比C++语言,是更加纯粹的面向对象语言,然而纵观各个Web产品代码,哪里还有面向对象可言,几乎清一色面向流程进行开发与维护,就是所谓的失血模型。从大的方向来分,所有的类分为两种,一种是承载数据的数据模型,只含有get和set方法;另一种是不承载数据的无状态类,所谓的事务脚本。这种开发,让整个软件像是一个大木桶,一个服务就是一个木片,需要新开一个功能就从服务接口到数据库一撸到底,这样的开发对于一个小型的软件来讲,非常好用,能够使软件快速成型,而且对于开发团队来讲,也比较好分配工作,每人一片,基于数据库模型,撸完就OK了。然而对于一个大型的项目,或者一个长期维护的项目来讲,事务脚本之间的相互调用,错综复杂,这简直是噩梦。

因此,领域驱动设计,被公司作为软件工程师的一项基本技能,特别是对于技术经理必须具有良好领域建模能力。对于我而言,这个曾经在GIS行业实践多年而不自知的领域建模,而如今在接触过很多面向流程的互联网软件开发后,确被正式提上理论高度。

 

 

你可能感兴趣的:(领域驱动设计,领域驱动设计)