领域驱动设计之入门级教程（上）

　　不知道本篇能否算作是入门级教程&＃xff0c;因为大概构思了一下&＃xff0c;里面有的是属于教程的东西&＃xff0c;有的是相关的知识延伸&＃xff0c;有的则什么都不是&＃xff0c;就算是一点初级的认识吧&＃xff0c;因为我也是接触不久。主要刚看完《领域驱动设计》&＃xff0c;是一本不错的书。我看的是免费的pdf精简版&＃xff0c;好像卖的话要$30&＃xff0c;大家可以买来看看&＃xff0c;应该是不错的。购买地址&＃xff1a;http://www.lulu.com/product/paperback/domain-driven-design-quickly/2117794

　　文中提到软件设计有很多方法&＃xff0c;其中一种较为出名的“瀑布设计”。过程就是业务专家提出需求&＃xff0c;软件分析人员根据需求建立模型&＃xff0c;然后开发人员根据模型进行编码&＃xff0c;至上而下的瀑布模式。这个模式应该用了很多年&＃xff0c;也应该有很多成功的案例。但是他应用的范围和年代都离我们远去&＃xff0c;我想它应该是比较符合需求变化不大&＃xff0c;或者是需求较为明朗。它的缺点也很明显&＃xff0c;就是信息的流向是单向的&＃xff0c;从业务专家-》软件分析人员-》开发人员&＃xff0c;不存在信息的反馈&＃xff08;也可能是刚开始的时候&＃xff0c;不需要反馈信息&＃xff09;。没有信息反馈的话&＃xff0c;后面的一个环节就会根据自己的理解和认识加入自己的东西&＃xff0c;就会离业务专家想要的东西越来越远&＃xff0c;出来结果之后&＃xff0c;就可能是返工开始的日子了。

　　另一个文中提到的就是&＃xff1a;XP&＃xff08;ExtremeProgramming 极限编程&＃xff09;。书中应该是不太推崇xp&＃xff0c;估计是和自己是讲DDD&＃xff08;Domain Driven Development领域驱动开发&＃xff09;有关系吧。敏捷出现的背景应该需求出现了问题&＃xff0c;也就是需求的变化&＃xff0c;而且是变更频繁&＃xff0c;模型就会变更频繁&＃xff0c;相应的文档也会变更频繁&＃xff0c;开发的代码也就变更频繁。这时候&＃xff0c;需要一种新的设计方法来支撑这种局面&＃xff0c;改变一下大家的工作方式&＃xff0c;于是乎“敏捷”诞生了。它推崇少些文档&＃xff0c;不要过度设计&＃xff0c;甚至是不要设计&＃xff0c;以先满足目前的需求为准&＃xff0c;进行代码开发&＃xff0c;尽早的让客户看到可以运行的最终版本。等到需求变化了之后&＃xff0c;再来进行重构&＃xff0c;每一次只要满足当前需求就可以了&＃xff0c;进行不断的迭代&＃xff0c;越来越趋近于客户的想象。

　　虽然它解决了部分的问题&＃xff0c;例如&＃xff1a;文档没有更新造成的误解、过度设计带来的开发进度失控、复杂性的增加、多做了无用功&＃xff0c;但是它也有很明显的缺点&＃xff0c;就是它提倡的“简单”&＃xff0c;对于简单大家都有自己的理解&＃xff0c;同时缺乏了真是可见的模型之后&＃xff0c;没有设计&＃xff0c;由开发人员进行重构的代码会越来越难以阅读和更改。同时这也是我锁担心的&＃xff0c;同时我个人对于敏捷也是保留的。

　　信息传递失真。

　　信息传递失真是说&＃xff0c;信息在传递的过程中会迷失本来的意思&＃xff0c;传递的环节越多&＃xff0c;失真的度会越深&＃xff0c;到最后可能就会变成另外一个样子。在http://www.zhiyonw.net/jjx1.htm中介绍了一下《信息失真成本》。

　　信息失真存在于各行各业&＃xff0c;在我们的软件行业也不例外。书中就例举了例子&＃xff0c;软件分析人员和业务领域专家在一起工作了几个月&＃xff0c;一起创建了一个正确的模型&＃xff0c;模型也代表了正确的领域知识。然后将模型交给开发人员之后&＃xff0c;开发人员在看到模型之后&＃xff0c;可能会发现在模型中的有些概念不能被正确的转换成代码&＃xff0c;然后他们就会以模型为基础&＃xff0c;加入自己的设计&＃xff0c;虽然也可以实现模型&＃xff0c;但是加入了很多自己的东西。随着开发的继续&＃xff0c;更多的类被加入系统&＃xff0c;原始模型和最终实现的差距就会越来越大。到最后&＃xff0c;很难保证系统的质量&＃xff0c;就算实现了&＃xff0c;可是后面的维护呢&＃xff1f;它能经得起实际环境的考验吗&＃xff1f;后面还能扩展吗&＃xff1f;都可能会出现问题的。

　　当然了&＃xff0c;书中举这个例子&＃xff0c;不光是为了说明信息失真的&＃xff0c;好像就没有这个意思&＃xff0c;是我自己想到的。它的本意是说一个模型虽然正确&＃xff0c;但不代表它容易转换成代码&＃xff0c;或者它的实现违反了不推荐的设计模式。这样的模型还是需要迭代的。我们应该选择一个更加容易和轻易转化成代码的模型。

　　产生上面问题的源泉就因为经过业务专家和软件分析人员建立的模型&＃xff0c;对于开发人员来讲还是不适用的&＃xff0c;有可能会违反软件设计原则&＃xff0c;或者没有办法很好的实现&＃xff0c;以为建立模型的时候没有考虑到开发这个因素。

　　书中给出的办法就是让开发人员参与到模型设计的过程中&＃xff0c;减少模型在开发人员角度的失真&＃xff0c;确保在设计模型的时候就考虑到后面的开发。

　　可是我觉得这也会产生问题。就是开发人员和业务人员的思考角度是不一样的&＃xff0c;甚至可以说是反着的&＃xff0c;过早的参与模型&＃xff0c;这时候模型还处于业务分析的阶段&＃xff0c;开发人员参与业务我觉得不太好。这个工作还是应该由架构师团队来完成&＃xff0c;架构师也是开发经验丰富的人员&＃xff0c;可以从开发角度来衡量模型的可性能&＃xff0c;模型能否容易的转换成代码。可是减少后面开发的复杂性和不确定性。

　　所以说这个模型的建立除了业务专家、软件分析人员&＃xff0c;还有一个重要的角色就是&＃xff1a;架构师。架构师是联系业务和开发的角色。既可以尽早的参与模型的建立&＃xff0c;发现业务流程的开发问题&＃xff0c;为以后的开发扫清一些不必要的障碍。同时也可以思考后面的软件架构和硬件架构&＃xff08;部署等问题&＃xff09;&＃xff0c;后续工作的分配。

　　关于如何进行领域驱动设计&＃xff0c;会在下一篇的&＃xff1a;领域驱动设计之入门级教程&＃xff08;下&＃xff09;中进行详细的介绍。

　　本篇就到这里吧&＃xff0c;说了一些个人的认识&＃xff0c;欢迎大家一起拍砖&＃xff0c;提出自己的见解。