这是martinfowler.com的Brandon Byars文章，详细点击标题见原文：
集成软件产品——ESB、ETL 工具、API 平台和云集成服务——不是直接解决业务问题的产品。它们不属于同一类别，例如，欺诈检测产品或分析产品或 CRM。它们是编程语言，捆绑了工具链和运行时以支持编译过程。当您购买集成产品时，即表示您同意使用这些商业编程语言构建集成本身。
集成工具几乎总是低代码平台，这意味着它们旨在通过提供图形设计调色板来简化开发工作，您可以将集成工作流拖放到上面。但在幕后，该平台将源代码保存为 JSON 或 XML，并嵌入了一个运行时，该运行时知道如何将标记解释为实际的机器代码。
简化接口的关键是接受更复杂的实现。
简化集成的代码当然是一项崇高的努力，集成工具可以提供帮助，但还不能足以在功能上构建干净的接口。
重要的是，判断一个接口是否容易使用的唯一有效判断是它的实际用户。
Google 本来可以要求我们提供更多信息以使他们的搜索实施更容易——例如，地理、新近度和流行度信息——但他们只提供了一个文本框来输入搜索，并且必须学习如何将这些因素应用到他们的算法。
同样的问题也适用于 API 设计（我将其广泛定义为包括同步调用和异步事件）。
干净的接口隐藏了实现细节，集成上下文中的这些实现细节之一是编程语言的选择。
我们需要转变思维方式，从思考如何使用我们的工具解决集成问题，转而思考如何构建正确的接口以最大限度地提高敏捷性。
使用通用编程语言来管理接口演变
像Java这样通用编程语言的生态系统发展迅速：测试工具、IDE、可观察性工具和更好的抽象的进步受益于此类语言所运行社区的庞大规模。而低代码平台的生态系统要小得多，限制了以相同速度推进的能力，并且平台约束将几乎可以肯定，开发人员必须使用供应商提供的工具链来编写和测试代码。这自然会对供应链和静态分析扫描等安全问题产生影响。这种工具在 Java 开源库等方面受到了很多关注，但在低代码世界的围墙花园中却很少受到关注。
低代码工具不足以处理通用编程语言可以处理的相同类型的复杂性：
我的一位同事描述了一个有争议的环境，他正在处理使用 TIBCO BusinessWorks（一种著名的商业集成工具）的任务。他向 TIBCO 团队发起挑战：他会派他最好的 Java/Spring 开发人员创建与另一个 COTS 产品的 Web 服务（在 Apache Axis 中编码的 SOAP 接口）的集成，并且他们可以让他们最好的 TIBCO 开发人员做同样的事情. Java 开发人员在午餐前完成了一个工作实现。TIBCO 团队发现该工具不支持 COTS 产品使用的旧版本 Apache Axis，大型企业中常见的遗留复杂性类型。遵循授权意味着回到供应商那里并更改他们的路线图或添加通用编程语言的扩展。Fred Brooks 在他的著名著作中称这种扩展为“偶然的复杂性”。
然而，比通过商业工具运行所有集成所需的偶然复杂性更令人担忧的是，这样的任务将重点放在实现而不是接口、系统而不是功能上。
集成工具在实施方面“思考”
由于跨 IT 系统范围解锁数据和功能的复杂性，集成工具被创建并在今天继续蓬勃发展。例如，您的实际客户主数据可能存在于 SAP 中，但客户生命周期的早期部分存在于 Siebel CRM 中。IBM 大型机系统仍然为一些客户处理核心计费；其他人的 Oracle ERP。现在，该企业希望用 Salesforce 取代 Siebel。引入新产品的业务团队自然明白需要一些时间才能获得正确的配置以使其适应他们的销售流程，但他们最不想要的就是被告知冗长的 IT 时间表只是为了整理系统之间的粘合剂。
应用程序集成的早期是企业服务总线 (ESB)，它将系统连接作为可重用组件与编排和路由分离。您可以在简化的视图中看到这种分离 Mulesoft 的 ESB，之所以如此命名是因为它旨在消除集成的“驴工作”：
由于业界渴望在总线上拥有企业范围的规范格式，因此在 ESB 世界中有一些自然的错误开始，但所有这些都共享适配器的概念，用于总线的输入和输出 - 系统被集成。在愉快的路径中，您可以使用像 BPEL 这样的语言来描述您的集成，它可以提供图形设计调色板和源图同构，就像它在 XML 中描述的过程一样。
该行业在很大程度上已从 ESB 转移，但您可以在现代 API 平台中看到它们的传统。例如，看一下 Mulesoft 的三层 API 架构。
Mulesoft 销售 API 管理平台和用于构建 API 的低代码运行时。您可以而且经常应该购买中间件基础设施，完全有可能将 API 网关与运行时分离，代理到以通用编程语言构建的 API。如果你这样做了，问题就出现了：如果你在 Mulesoft 运行时之外构建了所有的 API，你会使用 Mulesoft 的三层架构吗？
我对 Mulesoft 模型的主要批评是对实现问题的强调：因为我认为这导致我们将集成视为一种战术问题。（集成应该是战略问题）