在业务层，对依赖的聚焦迫使我们将流程合理化并进行精简。业务流程需要能够追溯到组织机构的愿景（关于“乌托邦”的理念）、组织的任务（实现“乌托邦”的战略）和为执行那些战略所需的广泛功能（产品管理、工程、市场、销售等等）[……]在应用层，我们尝试对操作进行分组。注意业务层已经将操作的运行时分组定义为流程，而在应用层，我们需要更加静态地对其进行分组。哪些操作是一类的，哪些不是？这就是应用层需要考虑的依赖问题。然而，只有在下面的信息层才能找到这些问题的答案，因为只有当操作共享同一份数据模型的时候他们才是“一类的”。因此，数据模型可以分为两组，分别是“外部”和“内部”。任何系统的“内部”数据模型又被称作“领域数据模型”，它们将永远不会对其他系统可见。与之相对应，系统的“外部”数据模型被称为“接口数据模型”，它们永远对外暴露并与其他系统分享。
最近，Ganesh有机会将这些理念变为现实，并参照此方法观看实际工作中的使用情况。对于每个失败的场景，Ganesh认为其罪魁祸首都可以归咎于违反了一个或多个依赖原则。因此，他坚信如果组织机构能够遵循这些规则，那么最终将能够“实现SOA”。当然，我们拥有多年以来的许多其他例子——关于SOA的失败和成功之处，以及相应的为了让SOA成功而遵循原则与规则的尝试。Ganesh概括出的原则，可以根据操作的层次分为四类：

业务层：

（1）可追踪性——实行核心治理，“确保每件完成的事情都与组织机构的愿景有关”。

（2）极简主义——挑战假设。

（3）领域洞察——理解业务的本性，“从基本原则重新构想业务”。

应用层：

（4）内聚与耦合——“那些属于一类的应该归到一起，并且在不同系统间仅保留最小限度的联系。”

（5）实施与曝光——“共用领域数据模型和业务逻辑的操作组都会转化为产品，而共用接口数据模型的都会转化为服务。”

（6）变体与版本——“识别出每个逻辑操作的多重并行类型，建立一种方法来支持其逻辑和接口的不断变更”。

信息（数据）层：

（7）内部与外部——“区分接口数据模型与领域数据模型”。

（8）内容与上下文——“将接口数据模型的核心数据元素与限定元素分离”。

（9）抽象与具体——“创建同时适用于内容和上下文元素的数据类型的层次结构”。

技术层：

（10）捆绑依赖——“在实现业务逻辑的过程中，避免在无关的组件之间引入新的依赖”。

（11）后期绑定——“推迟不可避免的依赖，直到最后责任点”。

（12）完成工作的合适工具——“使用最合适的机制来实现逻辑”。

对用于SOA的面向依赖思想的原则和理念，各位读者怎么看？它们是否已经对你曾经参与的某个SOA项目产生了帮助？现在你是否会考虑使用它们，或是基于自己的经验对其进行修订？