架构风格，就像艺术运动一样，必须在其发展的时代背景下加以理解，而这种架构比其他任何架构风格都更能体现这一规律。
经常影响架构决策的外部力量的组合，再加上一个符合常理的但最终是灾难性的组织哲学，注定了这个架构是无关紧要的。然而，它提供了一个很好的例子，说明了一个特定的组织理念是如何合乎逻辑的，但却阻碍了开发过程中最重要的部分。
历史与哲学
这种面向服务的架构在20世纪90年代末当公司逐渐成为企业时出现：与较小的公司合并，以极快的速度增长，并需要更复杂的IT来适应这种增长。然而，计算资源是稀缺的、珍贵的、商业化的。分布式计算刚好成为可能和必要的，许多公司需要可变的可扩展性和其他有益的特性。
许多外部驱动因素迫使这个时代的架构师倾向于具有重要约束的分布式架构。在开源操作系统被认为足够可靠来完成重要的工作之前，操作系统非常昂贵，而且每台机器都要获取许可证。类似地，商业数据库服务器带有拜占庭式的许可计划，这导致应用服务器供应商（提供数据库连接池）与数据库供应商展开竞争。因此，架构师被期望尽可能多地重用。事实上，所有形式的重用都成为了这个架构中的主导思想，我们会在“重用…和耦合”中讨论它的副作用。
这种架构风格也说明了架构师可以在多大程度上推动技术分区的思想，技术分区的动机是好的，但结果却很糟糕。
拓扑结构
这种面向服务架构的拓扑结构如图16-1所示。
并不是所有这种风格的架构的例子都有图16-1所示的确切的层次，但它们都遵循相同的理念，即在架构中建立服务分类，每一层都有特定的职责。
面向服务的架构是一种分布式体系结构；图16-1中没有显示精确的边界划分，因为它会随着组织的不同而变化。
分类
架构师在这个架构中的驱动哲学是以企业级重用为中心。许多大公司对他们必须不断地重写软件感到恼火，于是他们想出了一个逐步解决这个问题的策略。
业务服务
业务服务位于此架构的顶部，并提供入口点。例如，ExecuteTrade或PlaceOrder之类的服务表示领域行为。一个常见的试金石测试-对于这些每一个服务，架构师能否肯定地回答“我们是否从事…”这一问题？
这些服务定义不包含代码，只包含输入、输出，有时还包含模式信息。它们通常由业务用户定义，因此称为业务服务。
企业服务
企业服务包含细粒度的共享实现。通常，开发团队的任务是围绕特定业务领域构建原子行为：CreateCustomer、CalculateQuote等等。这些服务是组成粗粒度业务服务的构建块，通过编制引擎连接在一起。在这种架构中，职责分离是为了实现重用。如果开发人员能够以刚好的粒度级别构建细粒度的企业服务，那么企业就不必再次重写这一部分的业务工作流。逐渐地，业务将以可重用企业服务的形式建立可重用资产的集合。
不幸的是，现实的动态性挑战了这些尝试。业务组件不像建筑材料一样，一个解决方案可以持续几十年。市场、技术变化、工程实践和一系列其他因素证明了试图将稳定性强加于软件世界的努力是行不通的。
应用服务
并非架构中的所有服务都需要与企业服务相同级别的粒度或重用。应用程序服务是一次性的、单一的实现服务。例如，可能有一个应用程序需要获取地理位置的功能，但组织不想花时间或精力使其成为可重用的服务。通常由单个应用团队拥有的应用服务解决了这些问题。
基础设施服务
基础设施服务提供运营相关的能力，例如监控、日志记录、身份验证和授权。这些服务往往是具体的实现，由与运营部门密切合作的共享基础设施团队拥有。
编制引擎
编制引擎构成了这个分布式体系结构的核心，它使用编制（包括事务协调和消息转换等功能）将业务服务实现缝合在一起。这种架构通常与一个或几个关系数据库绑定，而不是像微服务架构那样为每个服务绑定一个数据库。因此，事务行为在编制引擎中以声明方式处理，而不是在数据库中。
编制引擎定义业务和企业服务之间的关系，它们如何映射到一起，以及事务边界在哪里。它还充当一个集成中心，允许架构师将定制代码包和遗留软件系统集成在一起。因为这种机制形成了架构的核心，康威定律正确地预测，负责这个引擎的集成架构师团队将成为组织内的政治力量，最终成为官僚主义瓶颈。
虽然这种方式听起来可能很有吸引力，但实际上它更多是一场灾难。
将事务行为转移到编制工具上听起来不错，但找到事务的正确粒度级别变得越来越困难。虽然可以在分布式事务中构建一些服务，但由于开发人员必须确定服务之间的适当事务边界在哪里，所以架构将会变得越来越复杂。
消息流
所有请求都通过编制引擎，它是这种架构中逻辑所在的位置。因此，即使对于内部调用，消息流也会通过引擎，如图16-2所示。
在图16-2中，CreateQuote业务级服务调用服务总线，服务总线定义了由对CreateCustomer和CalculateQuote的调用组成的工作流，每个调用还具有对应用服务的调用。服务总线充当此架构中所有调用的中介，同时充当集成中心和编制引擎。
重用…和耦合
这种架构的一个主要目标是在服务级别重用 - 逐步构建业务行为的能力，随着时间的推移，业务行为可以逐渐地重用。这个架构中的架构师被指示尽可能积极地寻找重用机会。例如，考虑图16-3所示的情况。
在图16-3中，架构师意识到保险公司中的每个部门都包含客户的概念。因此，面向服务架构的正确策略需要将客户部分提取到可重用的服务中，并允许原始服务引用规范的客户服务，如图16-4所示。
在图16-4中，架构师将所有客户行为隔离到一个单独的客户服务中，实现了明显的重用目标。
然而，架构师只是慢慢地意识到这种设计的负面权衡结果。首先，当一个团队主要围绕重用构建一个系统时，他们也会在组件之间产生大量耦合。例如，在图16-4中，对客户服务的更改会波及到所有其他服务，这使得变更具有风险。因此，在面向服务的架构中，架构师吃力地进行增量变更—每次变更都可能产生巨大的连锁反应。这反过来导致了协调部署、整体测试，以及其他拉动工程效率的因素的需要。
将行为整合到一个地方的另一个负面影响是：考虑图16-4中的汽车和伤残保险。为了支持单一的客户服务，它必须包括组织所知道的关于客户的所有细节。汽车保险需要驾照，驾照是人的财产，而不是车辆。因此，客户服务必须包括伤残保险部门不关心的驾照的细节。然而，处理伤残问题的团队必须处理单个客户定义的额外复杂性。也许这种架构最具破坏性的启示来自于这样一种现实：构建一个如此专注于技术划分的架构是不切实际的。虽然从分离和重用哲学的角度来看这是有意义的，但实际上它却是一场噩梦。像CatalogCheckout这样的领域概念在整个架构中传播得如此之少，以至于它们实际上都被碾得粉碎。开发人员通常处理诸如“向CatalogCheckout添加新地址行”之类的任务。在面向服务的架构中，这可能涉及在几个不同的层中的几十个服务，加上对单个数据库模式的更改。而且，如果当前的企业服务没有在正确的事务粒度上定义，开发人员将不得不更改其设计或构建一个新的、几乎相同的服务来改变事务行为。关于重用到此为止。
架构特性评级
我们现在用来评估架构的许多现代标准在这种架构流行的时候并不是优先考虑的。事实上，敏捷软件运动刚刚开始的时候并没有渗透到可能使用这种架构的规模类型的组织当中。
特性评级表中的一星级评级（如图16-5所示）意味着特定的架构特性在某种架构中没有得到很好的支持，而五星评级意味着架构特性是某种架构风格中最强大的特性之一。记分卡中确定的每个特性的定义见第4章。
面向服务的架构可能是有史以来最偏向技术分区的多功能架构！事实上，对这种结构缺点的抵制导致了更现代的架构，如微服务。尽管它是一个分布式架构，但它只有一个单一的量子，原因有两个。首先，它通常使用单个数据库或几个数据库，在架构中创建跨多个不同关注点的耦合点。第二，也是更重要的是，编制引擎充当一个巨大的耦合点，架构的任何部分都不能具有与协调所有行为的中介器具有不同的架构特性。因此，这种架构设法找到单体和分布式架构的缺点。
在这个架构中，诸如可部署性和可测试性等现代工程目标的得分是灾难性的，这两个原因都是因为这些目标得不到很好的支持，而且在那个时代，这些目标并不重要（甚至不是渴望得到的）。
尽管在实现这些行为方面存在困难，但这种架构确实支持一些目标，如弹性和可扩展性，因为工具供应商通过跨应用服务器和其他技术构建会话复制，倾注了大量精力使这些系统具有可扩展性。但是，作为一个分布式架构，性能从来都不是这种架构风格的亮点，甚至是非常差的，因为每个业务请求都被分割到了横跨架构中很多部分
由于所有这些因素，简单性和成本成了大多数架构师倾向的反比关系。这个架构是一个重要的里程碑，因为它教会了架构师分布式事务在现实世界中有多困难以及技术分区的实际限制。
