应用系统开发思想的变迁

　　据说取个高大上的名字就会很多人看，所以就用了这个名字。

　　历时两个半月时间终于看完了《DDD》，叹为观止，虽然以前给很多新员工讲过面向对象，不过看了之后才发现，原来理解还可以更深，还可以升华。它解决了很多困扰我的问题，甚至有的困扰了我几年。下面准备用一到两天时间再浏览一遍，然后把理解整理一下写出来，如果写的时候想的起来，就顺便写写我之前的问题和一些事件过的思想什么的。另外，虽然我是逐字逐字读下来的，但难免有些理解不清晰的地方，我理解了就会改回来的，嘿嘿。

　　据说人一生除了睡觉百分之四十多时间在走神（记不清了），我总觉得我能达到百分之七十以上，所以我又一次以走神内容为内容随一笔，上次我是记得从哪开始走的，这次走的比较突兀，完全记不得是因为什么了。。。

　　一.面向过程

　　最早的应用程序，作用应该是帮助人们做一些重复性的工作，小学课本上人与动物最大的区别---工具。。。软件。

　　比如说走路，走一步的时候是:

　　1.先抬脚跟（鞋跟，排除走路脚跟不沾地的人，比如某剧里的某星）；

　　2.脚尖向后蹬地；

　　3.脚离地，膝盖微曲；

　　4.这个咱就不继续说了，免得拖剧情，反正很多就是了。。。

　　这个时候的软件帮助人类完成这些过程化的重复动作，因为要走好多步啊，每次都考虑一遍这么走好麻烦（懒人创造世界这话我就不说了），让软件去每次重复一遍这个过程，又省事，又不容易出错，因为人难免走神嘛，漏个步骤就可能摔跤的，软件就不容易漏，这个例子好麻烦就不写代码的例子了，总之面向过程就是这样了，表述一个过程，帮助人们完成重复繁琐的工作过程。

　　二.面向对象

 　　以上和以下都是抛开了硬件的影响，既然是走神，思维跳跃一些也是可以理解的...吧。上面说的走路这个过程，其实有很大限制的，比如说得是同样的走法，同样的环境，可能有时候还得是同一个人，因为有的人腿就是很长，有的人腿里还有钢板膝盖就是不能弯曲是吧。那我想走的更自在怎么办，如果是从过程的角度来考虑，得判断吧，判断脚跟不沾地，判断地，判断水泥地，判断泥地，判断水地（？），判断腿长短步子大小，判断高跟鞋和重心的平稳之间的关系。。。还有好多什么什么的判断，这程序要是改点需求还了得了，这就是要程序员命的节奏，要是现在要让几个人在不同的地上面走或者游，然后判断几个人哪个比较勤快，有进取心，走或游的比较卖力，算了，不敢往下想了

　　那怎么办，先把判断都抽出来看看，脚跟不沾地的是人不同，判断地的是地不同...，不同的地走路依然是那么走，只是交互之间相互的作用力不一样而已，一直以来想要变得简单的办法都是把变化的范围缩小，让变化方式和频率不同的部分独立，那在地的问题上，自然就是让走路的方式和地分开，分别独立，不同的人的走路方式不同，那就把不同的人也独立开，这样就体现除了对象的概念，现在有了脚跟沾地的人，脚跟不沾地的人，水，泥地，水泥地；这就变得和现实的情况一一对应了，现在瞬间就能发现好处，既然和现实是对应的，那我完全不要去考虑程序过程的逻辑了，有木有，我只要按照现实人与地的交互来描述对象（现在可以起名叫对象了）之间的交互不就完全实现了需求，而且不会有错，因为就是照着现实的办理描述了一遍的，这太轻松了，这部分我之前写了个剪刀剪纸的随笔描述了对象交互，例子就略了，总之，面向对象的思想出现了（那些建立了很多对象，但是依然在描述过程的人是得不到这个好处的，就不细说了）。

　　三.DDD

　　DDD独立一个大序号，是因为它是我以后的重点，它依然是面向对象，但它是在一个大背景下的面向对象的升华。

　　接着走路，现在走路要走的精确点了，脚跟怎么用力，脚尖，小腿，膝盖等等...，这些器官间的交互，再加上和地的交互，脚跟怎么对地，脚尖怎么对地，还有鞋的问题，在这种情况下，面临了当初面向过程相似的问题，对象太多，对理解有很大压力，不是说人最多只能记住七样东西么，这么多对象难免思考怎么交互的时候会遗漏点什么，摔跤又难免了。就像小孩正常走挺好，但是走的太快，来不及协调所有对象，就容易摔跤；大人跑的可能很稳，但是那是因为协调了好多年才形成的，我们等的起，客户可等不起...。怎么办，同样还是缩小范围，将变化频率一样的东西放一起，走路时，人腿上的所有器官是协同变化的，形成了一个完整统一的系统，这个维持着一致性的系统起名叫聚合，现在又变回了原本面向对象的情况，协调又容易了。

　　现在再来看看上面那个比较哪个人更有前进心的问题，怎么比较呢，比较三种地，再联系三个人，再比较三双鞋，这时候其实还得考虑下，水里那位可不是只用了脚，而且水里的不赶紧游没力气了要喝水的外界因素，这种比较实在是有些头疼。怎么办，经典的方法之所以经典，就是因为好用啊，这里只要每个人所处的上下文归为一个聚合，给三个聚合一个比例指数，那三个聚合只需要内部处理的结果于自己这个聚合的指数比较就出来了，而内部的处理因为是在同一个上下文中又有能保证一致性的关系，就轻松多了，这样也把比较的范围缩小了。从这个角度来看，DDD的对象是一个又若干有一致性关系的小对象形成的系统的对象，和传统面向对象的外在表现其实并无不同，只是可能传统的对象并没有把人腿细化为各个器官的协作。

　　举个正在开发的工作流的例子，审批的单据包含特定审批类型所独有的单据内容以及相关的业务内容，业务内容中可能会包含一些明细，查看单据的场景就需要有三种对象：审批单信息，业务信息，业务明细信息，分别查看的话，每次都要关联查询三个对象的信息，这种查询的逻辑每次不同的查询方式都要做开发，比如发送审批邮件，移动端审批等，但其实这是没必要的，因为这三种对象是有一致性关系的，这种稳定的一致性关系都由开发应用逻辑的程序员来重复维护是没必要的（查询，保存等都需要维护），那完全可以使用聚合，将一致性保持在聚合中，而应用逻辑只需要知道使用单据就可以了：

　　　　　　　　　　　　

　　业务信息和申请单信息会有很多种类，但这并不影响这个结构的稳定性，这个系统由于正在进行中，所以就不发代码什么的了，而且由于是公司的系统，也不好说太细，开发完成以后我应该会做个总结，把能写的地方写出来的。