简单是王道《二、用组件化重构系统的思考》
目前公司的系统存在很多问题，最大的问题是没有好的架构。什么是架构呢？打个比方，建一栋高楼，首先要有概念设计，然后是建筑蓝图，然后是各种预算，然后是有计划的施工。这个过程的每一步是统一在一个整体当中的，要经过预先的有系统的思考，再经过论证，再不断进行细节的修正。我把整个过程和过程中对各种要素的规划称为架构过程和架构。再打个比方，医生的一次手术，首先要进行各种术前检查，然后对检查结果进行分析，然后确定手术方案。这个手术方案也是一种架构。软件架构师就是那个规划软件系统的人，软件系统应该是架构师经过系统思考后设计出的产物。

和建筑、特别是和手术不同，软件的生产过程不是一个反馈迅速的小闭环系统。软件系统的一次崩溃，打个补丁就过去了。功能不满足？再提供一个补丁。在建筑和手术中没有这么好的事。造成软件生产的这种大闭环系统的原因有很多......，结果就是造成业界对软件架构的忽视。为什么呢？因为就算没有经过系统思考，“楼”也不会倒，“手术”也不会伤人。架构师可以零零碎碎地思考，即使出了问题，也总是可以解决。在这种环境下，怎么能培育出真正有经验的软件架构师。

提提SOA先。SOA是目前业界非常流行的一种技术。面向服务来规划系统，从上而下地来实现系统，这种思路是非常正确的。不过我觉得，SOA只是在某个层面上构架系统的一个方法。它可以使老系统焕发青春。这里说的青春，是指老系统避免被淘汰的命运，可以在新的环境下面让这些老系统发挥作用了。但仅此而已。老系统没有演化，它没有从短颈鹿变成长颈鹿，它没有在肚子上长出一个袋子，它没有进化出跟随环境应变的保护色。很多老系统甚至没有任何机会演化，因为打了一千个补丁之后，上帝没有兴趣在演化系统的同时去演化那一千个伤疤。

重构是让老系统焕发青春的另一种方法。这种焕发是由内而外的。为了让演化成为可能，好的基因是关键。组件化就是这种好基因。

SOA关注的是服务模型。这没错。而服务通常是由组件提供的。对于服务的使用者来说，服务是关注的重点。而对于服务的提供者和实现者来说，在考虑服务的同时还得考虑服务的载体，换句话说，得考虑组件模型。而对于更具体的实现者来说，还得考虑物理上的组件模型。

组件是否要物理化？要。好处呢？物理化的组件更有利于软件资产的重用，更有利于多条具有共同特征的产品线的装配，也更有利于有效的开发模型的建立。总之，好处很多。

在组件化的时候，一些原则必须考虑。

1、有效率的开发模型；
2、严格控制的服务接口；
3、组件扩展和客户化机制；
4、组件封装和内部访问控制；
5、保持组件的独立性。

在组件之上还必须考虑流程。工作流的思想解决了应用软件开发中的很多问题。我觉得最重要的有以下几点：

1、解决了异构系统的集成问题；
2、系统功能块的可重用性大大提高；
3、配置（非代码）增加了系统的灵活性；
4、系统解耦能力全面提升。

可以说，SOA思想的快速普及也是得力于工作流平台的日益成熟。工作流为SOA提供了舞台。这里我想说说它对系统解耦能力的帮助。

在SOA中，应用系统的服务统一注册在ESB（企业服务总线）。为了解耦，ESB使用代理服务而不是真实的业务服务给客户。一个代理服务可以代表一组经过编排的业务服务。这些业务服务同样是注册在ESB中的逻辑意义上的服务，这些逻辑意义上的服务通过配置，最终定位到某台主机上的物理服务。解耦体现在哪里呢？你看，对客户来说，他们只知道代理服务，而代理服务的实现对于客户来说是透明的，这就给了业务服务发生各种变化的空间。这些业务服务可以重新编排，增加或减少，重新定位到不同的物理位置。在编排这些服务的时候，ESB提供了框架和标准的数据总线，使不同的业务服务之间可以任意交换数据。这样使服务之间的耦合性降到最低。

以上说的好像和工作流无关。的确没有关系。在这次重构中，我一直在思考用工作流（准确的说是规则流，或者叫微观工作流）来替代服务编排。服务编排是通过XML来传递数据（也被称为消息路由），在服务逻辑的分支、合并、跳转上存在不便。而强大的工作流引擎应付这种服务编排完全是小菜一碟。

还有一个重要的想法，即组件对客户来说应该是透明的，客户只和工作流打交道，换句话说，只和代理服务打交道。组件透明化使组件的变化对系统的影响最小。需要做的是重新配置流程，建立输入输出参数的映射。这看上去很美，呃？

目前重构一切顺利。过两天放上些具体的内容。