现在，我们已经标识了重要的抽象级别，让我们更深入地研究它们之间的关系。
如果您查看这些抽象级别，那么您将会发现，在这些级别中都指定了相同的“决策”种类：也就是，关于如何从局部的角度来组织软件、这些局部看起来是什么样子、它们如何组合起来，以及它们如何运转的细节。这些决策递归嵌套，并在较低的抽象级别中不断地添加细节。另外，如前所述，在较高的抽象级别中所指定的决策将约束那些在较低的抽象级别中所指定的决策。
“体系结构上的重要决策”指出某个在详细体系结构级别上很重要的决策。抽象的设计级别包含所有最重要的决策(关于软件结构、打包、接口，以及在实现级别中约束所有较低级别决策的连接)。最重要的是，我们指的是使用某种结构(在很长一段时间内保持有效的)提供整体体系结构的那些决策。例如，我们可以选定一些体系结构部分(组件)，以及一些最不容易随时间的推移而更改的接口。不必要的体系结构的更改可能是，仅仅因为持久性机制发生了更改而更改某个接口。应该将这类更改的影响限制于实现中的更改(从而将其限制于抽象的实现级别)。
正如您所看到的，体系结构概括了关于软件(和硬件)的最重要的决策，并且将它们限制于能够经受住时间考验的决策。决定哪些内容是或者不是体系结构中的一部分，看上去有明确的界线，但是这种分离是很重要的，它允许我们管理软件模型的复杂性。它还可以生成这些区别(这是经验丰富的软件架构师的最重要的技能之一)。
面向服务的体系结构构建块：SOA 解决方案堆栈
通过抽象重要概念和分离关注的事项，软件体系结构可以降低复杂性。对于面向服务的领域，SOA 解决方案堆栈提供了 9 个层次(分离关注的事项)，以及它们的逻辑体系结构构建块(抽象)，这些构建块可以用于在较高的抽象级别上表现面向服务的体系结构。
图 2. SOA 解决方案堆栈
要获得关于 SOA 解决方案堆栈的更详细的信息，请阅读文章“Design an SOA solution using a reference architecture”*(请参见参考资料部分)。本文的目的在于，说明可以将 SOA 解决方案的关注事项分离为五个功能层和四个非功能层。这五个功能层分别是：
操作层。包括运行于 IT 操作环境的应用程序组合中所有自定义的或者打包的应用程序资产，并支持各种业务活动
服务组件层。包含软件组件，这些组件为某项服务提供了实现、认识、或者操作
服务层。由所有的服务组成，包括在 SOA 内部定义的、与业务保持一致的一组(一个或者多个)IT 功能的抽象规范
业务流程层。定义在服务层中公开的服务的组合和编排
使用者(或者表示)层。提供向最终用户交付 IT 功能和数据以满足特定的使用偏好所需的功能
请注意，提供者更加关注底层功能层，然而，服务使用者则更多地关注于顶层功能层。
四个非功能层分别是：
集成层。提供服务请求从服务请求者到正确的服务提供者的中介、路由和传输的功能
QoS 层。为 SOA 提供实现非功能性需求 (NFR) 所需的功能
信息体系结构和业务智能层。确保包含与数据体系结构和信息体系结构相关的重要注意事项
管理层。涵盖 SOA 中业务操作生命周期管理的所有方面
