领域驱动设计之我见-面向对象思维
公司最近在推动研发体系员工技能图谱学习，其中对技术经理有一项基本要求是领域建模能力。关于领域驱动设计，埃文斯前辈出版过一本书《领域驱动设计：软件核心复杂性应对之道》，想必大多软件工程师都有读过，也对领域驱动设计有不同的见解，我的理解领域建模也就是面向对象建模。
我本身并非科班出身，原本是个地道的Giser，大学期间学的第一门语言是C语言，继而又学习了C++，也曾从事过几年的C++开发工作。入门学习C语言时，感觉计算机语言就是对大脑思维的一种抽象，像数学的计算公式一样，将思维符号化，然后使用符号计算代替人脑的推理。当开始学习C++时，感觉进入了一种全新的状态，我开始使用计算机语言模拟这个世界，使用类来模拟一个看得见摸得着的实体，而不在是C语言那样简单的将一串思维符号化了。这种编程思维反过来影响现实世界的看待问题的方式，当我面对复杂问题时，如何根据问题的上下文对问题进行归类，划分属性，理清所属关系，进而理出一个可行的方案，一步一步解决问题。
最开始做软件设计是一个课堂作业，做一个使用MFC开发一款CAD软件。设计思路很简单：定义一个基类graphic，然后派生出line、arc、rect分别代表线、弧、多边形；再定义一个基类graphicStyle，然后派生对应的style；最后通过MFC的document捕获鼠标输入，并绘制相应的图案。如下：
如上是一个典型的面向对象的设计方案，将现实世界的点线面抽象为计算语言中的一个个类，每个类包含自己的属性数据和方法。
然而，做了几年C++之后在一个不巧的机会，开始转做Java开发，进入互联网软件领域，虽然Java语言相比C++语言，是更加纯粹的面向对象语言，然而纵观各个Web产品代码，哪里还有面向对象可言，几乎清一色面向流程进行开发与维护，就是所谓的失血模型。从大的方向来分，所有的类分为两种，一种是承载数据的数据模型，只含有get和set方法；另一种是不承载数据的无状态类，所谓的事务脚本。这种开发，让整个软件像是一个大木桶，一个服务就是一个木片，需要新开一个功能就从服务接口到数据库一撸到底，这样的开发对于一个小型的软件来讲，非常好用，能够使软件快速成型，而且对于开发团队来讲，也比较好分配工作，每人一片，基于数据库模型，撸完就OK了。然而对于一个大型的项目，或者一个长期维护的项目来讲，事务脚本之间的相互调用，错综复杂，这简直是噩梦。
因此，领域驱动设计，被公司作为软件工程师的一项基本技能，特别是对于技术经理必须具有良好领域建模能力。对于我而言，这个曾经在GIS行业实践多年而不自知的领域建模，而如今在接触过很多面向流程的互联网软件开发后，确被正式提上理论高度。