大多数内部 REST API 都是一次性的，专为单个集成点而构建。在本文中，我将讨论非公共 API 的限制和灵活性，以及在跨多个团队进行大规模 RESTful 集成时吸取的教训。

一种模型（由 Leonard Richardson 开发），将 REST 方法的主要元素分解为三个步骤。它们引入了资源、HTTP 动词和超媒体控件。

良好的技术设计决策非常依赖于上下文。定期为共同目标合作的团队能够定期沟通并快速协商变更。这些团队表现出强大的协作力，并且可以制定技术和设计决策来利用这种强大的力量。当我们放大到更大的组织时，在独立工作且协作频率较低的团队和部门之间存在着越来越弱的力量。认识到这些强弱力量的差异，我们可以为每个级别做出更好的决策并提供更好的指导，从而使团队能够更快地行动。

商业集成工具已经存在几十年了，但是几乎没有关于何时以及如何使用它们的总体架构原则。在本文中，我认为“购买”决策机制导致我们夸大了此类工具的价值主张，通常导致强制使用某种集成工具而不是通用语言。我声称，此类工具在将集成主要视为连接系统的世界中蓬勃发展，但数字化组织已将集成重新构想为主要是在数字功能前面放置清晰的接口，强调功能而不是系统。最后，我列出了现代集成视图背后的一些关键原则，并声称最好使用通用语言来管理它们，重新定位商业集成工具的主要价值主张，以简化战术实施问题。

我的同事 Jim Webber 在企业集成方面采用轻量级和面向业务的方法，因此享有盛誉。他还以其健谈和有趣的演讲风格而闻名。因此，当我在 2008 年 QCon 大会上与他一起做主题演讲时，我既紧张又兴奋。他准备了一场非常有趣的演讲，其中穿插着一些严肃的内容。然后我们就开始了——可能是演讲前的啤酒起了作用。我们谈论了企业集成的历史、那些自以为强大但实际上只是臃肿的系统的增长、敏捷思维的作用、网络的影响（包括吉姆关于网络为何被发明的独特理论），以及这如何导致游击队 SOA。

本文讨论了服务提供者和消费者社区发展过程中的一些挑战。它描述了当服务提供者更改其契约部分内容（尤其是文档模式）时出现的一些耦合问题，并确定了两种广为人知的策略——添加模式扩展点和对接收到的消息执行“刚好够用”的验证——以缓解此类问题。这两种策略都有助于保护消费者免受提供者契约更改的影响，但它们都没有让提供者了解其使用方式以及在演进过程中必须维护的义务。本文借鉴了其中一种缓解策略（“刚好够用”验证策略）的基于断言的语言，描述了“消费者驱动的契约”模式，该模式使提供者能够洞察其消费者的义务，并围绕交付消费者所需的关键业务功能来集中服务演进。

近年来，关于无模式数据的优势的讨论越来越多。无模式是人们对 NoSQL 数据库 感兴趣的主要原因之一。但是，无模式涉及许多微妙之处，无论是在数据库还是内存数据结构方面。这些微妙之处存在于无模式的含义以及使用无模式方法的优缺点中。

我使用术语“应用程序数据库”来指代由单个应用程序控制和访问的数据库（与 集成数据库 相反）。由于只有一个应用程序访问数据库，因此可以专门定义数据库，以轻松满足该应用程序的需求。这会导致更具体的模式，该模式通常比 集成数据库 的模式更容易理解，而且通常也不那么复杂。

限界上下文是领域驱动设计中的一个核心模式。它是 DDD 战略设计部分的重点，该部分全部是关于处理大型模型和团队的。DDD 通过将大型模型划分为不同的限界上下文并明确它们之间的相互关系来处理大型模型。

当我谈论数据库以及它们与应用程序的关系时，我发现区分两种数据库风格很有用：应用程序数据库 和 集成数据库。两者之间的区别在于数据库是否在单个 应用程序边界 内进行控制和封装。

在本世纪初，我写了我的书《企业应用架构模式》。我在写这本书时遇到的一个问题是如何给它命名，或者更确切地说，如何称呼我正在写的这类软件系统。我一直意识到，我的软件开发经验一直集中在一种特定形式的软件上——比如医疗保健记录、外汇交易、工资单和租赁会计。这些与打印机、游戏、飞行控制软件或电话交换机中的嵌入式软件截然不同。我需要一个名称来描述这类系统，并最终选择了“企业应用程序”一词。

就在最近，我在亚马逊上收到了一些关于《企业应用架构模式》的差评，因为书中没有关于企业架构的内容。当然，这有一个很好的理由——这本书是关于企业*应用程序*架构的，即如何设计企业应用程序。企业架构是一个不同的主题，即如何将企业中的多个应用程序组织成一个 cohérent 的整体。

SOA 可以用敏捷方法来做吗？

SOA 狂热者所宣传的服务新世界的一个特点是注册表的概念。这通常是用自动化系统的术语来描述的，这些系统将允许系统自动在注册表中查找有用的服务，并自行绑定和使用这些服务。

好吧，计算机偶尔可能看起来很聪明，但我并不特别相信这个想法。虽然可能存在自动服务查找的特殊情况，但我认为二十二次中有二十二次是人类程序员在进行查找。

集成数据库是一个数据库，它充当多个应用程序的数据存储，从而跨这些应用程序集成数据（与 应用程序数据库 相反）。

随便找一家大型企业，你通常都会发现一些专注于企业级概念建模的团队。最常见的是数据管理团队，偶尔他们也可能参与定义企业级服务。它们是企业级的，因为它们不是专注于单个应用程序的工作，而是专注于集成多个应用程序。

对于任何为面向服务的架构构建服务的人来说，这是一个重要的想法。在构建服务时，还要构建一个 服务存根，供客户端用来进行测试。这样的存根应该为一组固定的请求提供预设响应，模拟错误情况，并且能够在客户端机器上运行。你需要确保存根能够正确地模拟真实系统的行为。通过为客户端提供存根，你可以让客户端更容易地使用你的服务；这当然意味着你的服务更有可能被使用。

让我们想象一个美好的 SOA 幸福世界，在这个世界里，企业的计算需求被分解成许多小型应用程序，这些应用程序相互提供服务，以实现有效的协作。一个美好的早晨，一个消费者服务需要来自供应商服务的一些信息。问题是，尽管供应商服务拥有获取此信息的必要数据和处理逻辑，但它还没有通过服务接口公开该信息。供应商有一个潜在的服务，但它实际上还没有。

每当Thoughtworks让我在客户面前露面时，我都会被问到一个问题：“您如何看待SOA（面向服务的架构）？” 这是一个几乎无法回答的问题，因为SOA对不同的人意味着截然不同的事情。

使用Web服务的好处之一是，它可以帮助您解耦系统的各个部分。 人们可以在一定程度上分离的情况下在不同的代码库上工作。 尽管您获得了一些解耦，但您不能完全消除耦合，因为服务仍然必须通过其接口相互通信。 可悲的是，许多团队使这种耦合比应有的糟糕得多。