SCA在业务、架构和实现层面对变化的适应性

　　小的时候特别羡慕高年级的同学能用钢笔写字。有时候用铅笔到墨水瓶里面占一下，除了能留下一滩墨迹外，写出来的还是铅笔字。不过，用铅笔写字有一个好处，就是写错了可以用橡皮擦掉重写。这也是在有了钢笔，可以用钢笔写作业之后才知道的。

　　在写程序的时候，经常要设置一些变量，什么局部变量，全局变量。和常量相比，变量有一个好处，在需要计算的地方使用，可以随时修改参与运算的值。就有点象铅笔写的字需要的时候可以擦掉重写一样，在需要改变参与计算值的时候不必修改程序中的计算表达式了。

　　铅笔写的字对于变化的适应要比钢笔好。变量对变化的适应要比常量强。

　　如果一个系统可以快速适应用户需求的变化，象修改铅笔字一样修改不适合的功能，象变量一样快速适应用户对系统的新需求，这个系统就是一个对变化的适应性非常强的系统。一个对变化适应性非常强的系统有什么好处呢?还是举一个例子。

　　在刚刚用钢笔写字的时候，老师总是要求用方格本写，不能有错字，不能写错了划掉，写错了就要整页重写。如果在刚刚写第一行就写错了字，那就撕掉重写，反正写的也不多。如果写最后一行出现错字，那还是要撕掉重写，不过那样就很不合算了。对于一个项目或者系统，如果在项目初期或者软件刚刚投入使用的时候发现一些问题或者不准确的需求，作一些更改成本可能还低一些。如果到了项目的后期或者系统已经投入使用甚至已经用了一段时间，再发现问题或者提出新的修改需求，对于那些对变化适应性很低的系统那等同于推翻重做!如果不推翻重做，而是在原有代码的基础上修改，付出的代价有可能是原来项目的几倍甚至几十倍。

　　一个系统的变化主要有三个层面：业务层面、系统架构层面和程序实现层面。

　　1、业务层面：针对与业务层面的需求变化有很多的解决技术，比如工作流管理系统就是为了适应用户业务流程的变化，利用可视化的流程定制工具，根据用户业务的变化通过配置动态修改系统的流程模型满足用户的需求。在SCA架构中，一个SCA Domain类似一个工作流管理系统中的流程定义。SCA Domain是SCA架构中粒度最大的组件模型，通过装配的方式可以提供业务功能的实现。SCA Domain由任意个Composite组件组成，Composite提供了基本的业务功能和逻辑，SCA Domain通过装配把Composite组合成符合业务需要的逻辑。当业务发生变化，SCA Domain可以快速响应，以适应业务发生的变化。

　　2、架构层面：SCA从字面理解就是面向组件的架构，所以在架构层面体现的是标准的架构模型。SCA的本质就是通过架构层为业务层和实现层提供组件的灵活性、可插入性、可替换性的机制。在架构层Composte组件可以将已有的组件纳入到新的组件之中，使之成为新组件的一部分，为新组件提供部分功能。这样做的好处有：

　　A、新组件访问已有的组件只能通过唯一的方法，就是已有组件提供的services

　　B、新组件对已有组件的使用是一种黑箱复用，已有组件的内部细节对新组件不可见。

　　C、这种复用支持包装。

　　D、复用低偶合，依赖少。

　　E、每个新组件可以专注与一个任务，责任清晰。

　　F、复用可以在运行期间内动态进行，组件可以动态引用其他的实现完成相同或者不同的系统行为。

　　G、可以通过promote选择对外提供的服务，增强可替换和可选择的机制。

　　当业务流程变化或者系统性能需求带来的变化，都可以通过替换、选择和组合的方式来增加(扩展)和改变系统的行为，当然有些需要实现层面提供必要的支持才能完成。

　　3、实现层面：通过component的支持，可以为架构层提供各种形式的语言和规范的实现。可以发挥各种语言、框架、规范的优势，最大限度的使用他们的最佳特性。component就象是一个适配器，将任何一种component支持的实现(如果没有可以自己实现)接入composite中，为架构层提供实现。

　　三个不同层面对变化的适应能力为系统提供了灵活可靠的对业务需求和系统性能需求带来的变化的适应能力。业务层的装配描述、架构层的提升和组合机制以及实现层对各种不同类型语言框架的支持带来的不同实现是系统随需而变有利的保障。

查看本文来源