OOAD和SOA的一些个人体会

       SOA作为整合历史的系统，和现有的各个分立的系统有先天的优势，但SOA作为一个革命性的新软件开发方法论的面目出现，更深层次的原因在于它对于复杂性的处理方式有别于以前的方法论。

      我们可以简单的将开发的复杂性归结为对各个领域对象的状态的控制上，意思就是如果在任何时刻系统的领域对象的所有状态是明确可知的，那么就可以说这个系统是可控的。

      可以推断出随着业务领域的复杂程度提高，领域对象会不断增长，这个问题还不是很大，线性增长，毕竟还是可控的，但是考察整个业务领域的状态来看，其复杂度是和领域对象个数成指数增加的。

      在简单的业务范围，领域对象少，那么用结构化的方式也可以应付的，通过自顶向下的方式，将系统分解为模块和函数来控制系统。这个方法的弊端我想大家都很清楚了，就不赘述了。到底领域对象增长到多少这种方法就无法应付呢。这个没有具体统计，只是看到用这个方法论来指导的开发在实践中不断的失败。

      这时候OOAD的方法论出来了，通过封装，继承，和多态的手段，各种设计模式如雨后春笋一样，可管理的领域对象数量得以大大增加，成功的案例不断增多，但是通过统计，我们还是不断的听到有一些大型的项目的投资失败了。

      原因是什么呢，关键是对这个复杂性的处理，目前有两种手段，一个是加强对复杂性的管理水平，尽量穷尽各种手段来分解并管理复杂性。一种方法是减少复杂性。
     
      OOAD方式是前一种，而SOA则是后一种。也许大家很奇怪，业务领域本来就是这么复杂，怎么减少他的复杂性呢？答案是分区，当你将业务领域分开为多个完全独立的区域的时候，复杂性就不是指数增加，而是变成线性增加的方式了，SOA通过提供软件自治概念，松耦合，无状态的Web服务，将各个部分变成完全独立的地址透明的服务，原来看来非常复杂的业务领域就突然变的不那么复杂了。至少复杂度不再指数增加了。

也许大家可能说什么自治，松耦合，无状态这些概念在OOAD里面也有啊，我也会将系统水平和垂直划分为很多个子系统和层啊，这个我相信，好的架构师会做到的，但是就整体来看，子系统并没有脱离系统，和系统在逻辑上和硬件上的耦合还是很多。
      说了这么多，大家都是对OOAD是不是很失落呢，毕竟大家都是从OOAD走过来的，是不是要放弃OO思想呢，这个我想不是的，在一个相对可控的领域，用OOAD的方式可以很好工作，范围大了后，可以考虑在这个系统上提供出Web服务来也是可以的。当然想完整实现SOA的话，必须用整套方法论，以前结构化编程的自顶向下的思想又重新回来了，所以说没有什么是绝对的，要考虑上下文环境。
 
      时间仓促，写的很粗糙。 欢迎大家和我交流 dfchengcn@yahoo.com.cn.