领域驱动第四章-读书笔记

以后简称作者为巨牛。^_&

第四章讲解的重点就是分离.领域的分离.

说实在的,读之前觉得,自己的设计模式用的也比较熟练了,OOP的设计也做过很多个了,分离什么都是小儿科.读完之后才发现,以前的设计都是智能UI设计.一种无法复用,无法正确扩展的设计.

首先,书中解说了下为什么要分离,核心思想就是:解耦.

然后，明确指出，领域要和什么技术实现啊，用什么缓存之类的统统隔离。越简单越明了就越好.

然后在最后提出了一种很不好的设计:智能UI设计

来说下巨牛对智能UI设计的解释:

把所有的业务逻辑交给用户界面处理。把整个应用程序分割成小的功能函数(也就是小的业务模块,如何分割的话就要看模块之间的关联度了)，并且把他们作为相互独立的用户界面来实现，同时把业务规则嵌入到这些界面中（我觉得如果在界面中涉及到过多的业务逻辑,就算把业务规则放在service层中实现，也还是相当于把业务规则嵌入到界面中了）.用一个关系数据库作为数据的共享仓储.使用最自动化的UI结构,以及可利用的可视化编程工具.

然后列举了智能UI设计的优势和缺点.(呵呵,我还是比较认同的,客户的要求是最重要的,特别是针对的是项目,如果是产品的话,就不能这么做了).先说优点:

1. 对于简单的应用,生产力较高(呵呵,还是较高而已),开发时间较短.

2. 缺少经验的开发人员可以进过较短的培训直接上手.

3. 甚至在进行需求分析时所留下的缺陷,可以通过把原型提供给用户来克服,并快速的在软件中做出修改来满足用户的要求.(这个一定要是简单应用啊).

4. 应用可以相互分离,所以能够精确的计划递交小模块的进度表.对系统的简单扩展可能会很容易.

5. 关系数据库工作可靠,并且提供数据级上的集成.

6. 第4代语言（JAVA什么的）功能能很好的满足开发需要。

7. 档这个应用程序被递交后，维护程序员能够很快的重新开发他们（开发人员）没有解决的部分，因为改变所带来的影响只局限在每个特定的UI中。

好了，列了很多优点后，现在开始说缺点了：

1. 应用的集成比较困难，除非利用数据库。关于这点说下我的想法：比如开始做了个人事考勤的系统，里面有组织结构模块，人员管理模块，考勤模块。现在呢，客户又想要个考试管理，那么我的人员管理模块和组织结构模块在当时没有考虑支持其他系统的功能，最简单的做法就是把数据库放到一起去，后加的功能直接去访问数据库。再呢，就是改原来的。反正就是不能重用。

2. 这里不会考虑重用以及业务问题的抽象。业务规则必须在每个使用它（上面提到的人员管理模块）的操作中复制。

3. 缺少抽象的提炼而限制了重构的选择（比如考试系统中有学员和教师等各种角色），所以快速原型和迭代收到了天然的限制。快速原型的概念：http://baike.baidu.com/view/408667.htm

4. 复杂性很快会让你迷失（这个真的只能意会了），所以增长路线只能严格顺着原有的应用上添加简单应用而已。想要获得具有丰富行为的应用并不容易。

总结就是：如果一个基于产品的简单项目，客户拿去忽悠赚钱的，用一次就丢掉的项目，用智能UI设计的方法是基本上没什么问题的。但是，采用这种模式的一个后果就是你不能把它移植到另外一种设计方法中，除非替换整个应用程序。

好了，第四章看完了。有些启发，有些疑问。需要在后面的章节中寻找。

Domain-driven design