企业倾向与频繁地改变架构。以服务为中心和全球化的发展会不断强化这种趋势。这个世界正在逐渐变成一个以业务架构为中心的网络，在这个网络上存在着独立的、自治的服务提供者和服务使用者。部分的业务流程也会被外包给外面的公司。

　　部门将会转变成服务提供者。这些服务提供者不再仅仅服务于组织内部，他们会寻求外面的市场来提供自己的服务。随需应变的业务正在成为潮流，而那时服务提供者将会对来自于环境中的刺激——事件做出反应。

　　要想在充满竞争的市场中胜出，高度的自治是必须的，它需要能够自由地选择合适的IT支撑系统。独立性的不断增长需要应用组件间松散地耦合，从而保证业务流程能够服从于不断改变的组织架构。

　　为了达到这种敏捷性，支撑应用必须能够迅速适应组织的改变，例如职责和角色的改变，外包或者内包，部门或者整个公司的分解，融合或者重组等等。

　　业务流程一定不能被IT系统限制，要紧紧地跟上着这些组织的变化。例如，部分流程要外包出去，相应地部分IT系统就可能被砍掉，剩下的IT系统就必须能够与外包公司通信。为了适应新的形势，IT系统的改变一定不能耗费太多的时间和金钱。

　　SOA，虚假的承诺

　　这些都需要应用组件之间松散地耦合，以便轻松地改变组织架构而不用去改变IT系统。但是SOA的本质是同步地命令控制模式，这是一种应用组件间紧耦合的方式，它是无法满足这种伸缩性的。

　　SOA在技术领域内可能是松耦合的，它采用了标准的web service。但是在功能领域，SOA做不到松耦合，因为它是与外部服务调用和数据冗余消除相互联系的。外包后，业务和数据的可用性将消失，这可能会造成巨大的损失，而这些全都是因为SOA引起的。SOA的承诺是松耦合，但是在功能层次上，这可能是一个虚假的承诺。

　　IT弹性与组织弹性

　　毫无疑问，SOA的采用将会带来益处，它会缩减IT指出，并且加快部署。

　　但是同时SOA被定位于命令控制模式的，在功能分解上，它采用粗粒度。为了在先前提到的组织转变环境中达到松耦合和自治，EDA在这个粒度层级上将会更加合适。EDA将会保证组织本身弹性，EDA将会帮助企业在不影响应用架构的基础上进行组织改组。在不改变应用的情况下改变组织的架构这是EDA的承诺。当然我们这里讨论的敏捷性是在一个完全不同的层次上的。

　　粒度

　　但是为什么SOA采用这样一个级别的粒度?有四个方面的原因。首先，大多数人都根据web service来理解SOA。其次，当前的web service不适合细粒度。第三、web service起源于请求应答模式，所以它与命令控制方案紧密相连。第四、事件驱动模型还很少有人知道，而人们都喜欢在自己熟悉的领域里来寻求解决方案。不幸地是，命令控制模式不适合这种细粒度。建立在同步web service上的SOA，对于中等层级粒度上的功能分解可能是个好主意，但是你也必须在设计前进行详细地调研。所以寻找SOA适用的合适的粒度不是一个小问题。

　　何时采用SOA，何时采用EDA

　　同SOA相比，EDA提供了松散地耦合。EDA不是同步地命令控制模式，恰恰相反，它是一个异步地发布订阅模式。发布者可能完全不知道订阅者是谁，组件被松散地组合在一起，它们之间仅仅地共享消息语义。

　　如果你希望实现业务流程的高聚合，所有的流程都处于统一的控制之下，SOA会比较适合。SOA的命令控制模式适用于如下情况：

　　◆ 在功能分解的层级之间实现垂直的交互

　　◆ 功能性的请求答复流程，例如人机对话，用户会等待机器的响应。

　　◆ 需要方便提交和回复的交易流程

　　如果你希望实现业务流程之间的独立性的化，EDA会适合你。这种架构风格非常适合联邦制和自治的流程环境。EDA适应如下一些应用：

　　◆ 流程链上每个环节之间水平的交流。

　　◆ 工作流;

　　◆ 那些跨越组织边界的流程，需要内外的交互，如B2B。

　　找到那些你能保证会停留在同一组织体内部的业务流程，你将会发现解耦的要点，它就是业务功能的边界。

　　在所有的粒度水平上实现松耦合是最理想的，这样伸缩性和敏捷性就能方便地实现。所以我们应该遵循如下规则：除了需要命令控制模式以外，任何情况下都采用松耦合。不管是SOA还是EDA，在功能维度上这些都是适用的。当然，这些规则总是会受到性能方面的挑战，例如快速地应答。