在系统分析和设计领域,我们所拥有的思想方法林林总总可谓蔚为壮观,从早已成为古董的过程式到如今几乎一统天下的面向对象,再到现在的面向方面,组件化等等,这算是主流,在这之外,还有函数式编程,STL模板式,动态语言等,无一不是为了获得更强大的计算机表达能力而设计进化,而所依据的却是更多地靠近人类的思维习惯,然而至今所有的努力都依然没有让人们有一种获得"银弹"的感觉,系统的复杂性总是产生在性能和简单性微妙的平衡之间,产生于可控性架构和动态变化需求之间微妙的边界,而正是这种微妙,最终毁灭了最初设计时看起来的所有壮观与精妙,如同混沌系统一样,在经历过三五次的来回往复之后就进入无可避免的混沌状态,这个时候任何一个细节的变化都会造成全局的改变,而任何一个细节的有意无意的忽略都将成为最终引起风暴灾难的蝴蝶翅膀.设计师的重任,就是尽可能多的抓住这些细节下隐藏的魔鬼.

现在回头看所有的的分析设计思想,我们是不是该反思一下这些设计思想是不是过于"溺爱"于人类的思维方式了,而这种"溺爱"却蒙蔽了我们有限思维能力的智慧之眼,偏离了系统存在的本质?

人类语言发展到今天,其实是历史演化的结果,人类思维方式发展到今天,当然也是历史演化的结果.是不是今天我们人类的思维方式已经达到了智慧的最高成就呢?我想恐怕不是,不但不是,更可能是远远的不是.所谓的历史演化,其实就包含了历史轨迹惯性下的限制,这就好比人的习惯,一方面习惯在做很多的事情的时候带来巨大的效率,另一方面却总在突然事件面前造成无数自以为然的判断失误,从而酿成灾难.

面向对象就是如此.当我们辛辛苦苦把一切都塞入面向对象的世界的时候,却发现需要面向方面的横切,当我们处理面向方面的时候又面临描述上的困难与不自然,当系统变得越来越庞大的时候,这些困难就变得越来越明显,组件化的处理方式就成为智能有限的我们的共同选择 ---- 其实不是计算机限制了我们的智慧,而是我们的智慧限制了计算机的计算能力.

想想看,我们系统里运行的那些代码,对于计算机来说,其实都无非是一次又一次的重复,而当我们不能给出更多代码的时候,计算机只有去浪费电力而不做任何事.当我们在语言里彻底取消罪恶的goto语句的时候,我们驱使计算机做更多有趣事情最强大的方法其实只有一个:迭代.而这个迭代也只是少量变化下的有限代码的循环调用,一旦代码的复杂度超过我们智能所能控制的边界,就将成为灾难.

其实系统分析与设计思想进化到今天,无非是想实现一件事:对计算机更强大的控制力. 关键词就是控制二字.为了实现控制,我们采取了全面倒向人类语言与思维方式的路线,而不是更多地思考系统存在的本质.

我们现在这种对计算机奴隶式的控制方式总有一天会无以为继,实际上,google庞大的搜索系统已经触及到了这个控制方式的边界,当google试图建立一个人工翻译机器人的时候,就已然开始超越这个边界了,因为要做到这件事,只有依靠计算机本身的计算构造全新的代码才能做到,不管这种代码将表现为何种方式,这种代码的产生都将不可避免.或许你会说这其实就是人工智能,但是这个人工智能却不是传统意义上的人工智能,而是一种未知结构与人类可控性之间的博弈,一种放手让计算机自己去发现新结构而又不能让整个系统失去控制之间的微妙平衡.

面对强大的核能量链式反应,我们所需要的只是中子棒,而不是去规定链式反应的过程,这才应该是人类智慧该干的事.

因此,我们今天在系统分析和设计领域所做的事情,仍然太多了,计算机的能力没有得到根本的解放,我们总是把自己当做计算机来运算,然后让计算机来运算.

抛开计算机的一切,我们回到系统的本质,其实我们很快就能发现,我们所希望的,只是计算机能够帮助我们自动维护一个结构,(计算机发现是一类发现结构的结构),而我们能够获得这个结构本身.

因此我们才会想到更加接近人类语言与思维的描述方式去描述这个结构,然而这却远离了准确表述结构的方法本身.

其实,建立计算机理论本身的语言,正是当下描述结构的最好语言:数学.

数学这两个字或许让无数的人头疼,然而如果换一种思维,数学本身清晰的理论逻辑体系,或许才是适合于人类思维最好的方式,虽然在当下数学仍然不能取代人类语言,然而在建立更强大的控制力方面,数学却无可争议地趋向于全面取代人类语言,而另一方面,人类语言也更多的具有数学的特征了.

在描述结构方面,现代数学的基础集合论却是不二之选,虽然面临着集合悖论,然而这种悖论本身可以用集合来表示就意味着集合表达结构的强大能力,悖论本身只是说明了集合的判断难题,是一个逻辑难题,而不是表示的难题.

集合是简单的,但却可以用以表达所有的结构,这正是集合的强大所在.

拿现在面向对象的语言来说,类本身就包含了两个集合的内容:一是类本身内在的属性结构的集合,这个类表示了一个对象的集合.

然而,现实世界中的集合远远不止这两种,更多的集合其实是集合的集合,集合的子集,实际上,类的属性本身就已然是这种集合存在的证明,因为属性本身就是另一个类与本类的关联,如果以这种关联划分的话,那么这个被关联的类下的对象集合其实就是所有对象的一个子集.

而偏偏现在的所有语言都没有意识到这一点,而正是这一点,造成了分析设计领域里的无数难题,其实面向方面里的那个切面描述,不正是一个集合的描述吗?

如果我们一开始就将这一切都视为集合,而让代码像面向方面里一样去自动组织,那么问题将迎刃而解了,何必又要引入一套新的语法呢?

而如果我们一开始就以集合为视角来分析设计系统,那么我们怎么会面临联合查询,组合查询,动态查询等等的麻烦事?实质上,查询本身就意味着一个新的集合,而据我的观察,几乎所有提供动态查询的系统,其实都会出现性能和架构上的难题,而对于客户来说,他们经常使用的查询组合,却是相对固定的!只是我们根本就没有仔细区分每一类用户的兴趣点在哪些集合上而已!

这个做法,从根本上简化了设计思路,更是从根本上弥合了从需求到设计的鸿沟,而不再是需求语言到计算机语言的翻译过程,而是一个直接的需求到实现的细化过程,因为,从始至终,我们都是用的同一种语言方式来描述的,只是这个描述随着与计算机的结合而越来越详细罢了.

从计算机内部讲,由于我们只是控制了结构与规则,则可以由计算机完全自主控制并发,使得可以最大限度利用并发计算来解决性能问题,而并发,可能才是利用计算机最强大的方法之一. 规则的本质就是最大限度化并发.

再次设想,如果整个计算机体系一开始就面向集合来处理的话,恐怕现在的计算机会更好用......

但是作为一种思想,面向集合,SOA & SOD, 却是在分析和设计领域值得发扬的.