用组件库构建更干净、更干燥的API

组件库也可以成为从一开始就开发更干净、更耐用、更有弹性的代码库的秘密成分。在您职业生涯的某个阶段，您无疑遇到过DRY 代码的概念 – 该缩写词代表“不要重复自己”。下面，我们将探讨干净代码的一些原则，以及为什么它们对 API 如此重要。我们还将了解两种常见的开发工作流程以及每种工作流程的优缺点。

使用干燥、坚实的基础防止服务潮湿

一位导师曾经告诉我，“所有代码在 15 分钟后都是遗留代码。”编写干净代码的最佳理由是留下一些遗产，在您继续前进后对其他人有用 – 即使只是在您继续吃午餐时。对于 API 开发人员来说，这意味着编写易于在 API 双方（生产者和消费者）工作的其他开发人员使用的代码。

强调干净的代码非常适合实用的API 即产品心态；如果您认为这只是极客性能优化专家的领域，那么您就忽略了该方法的一些关键优势。将您的 API 程序视为一流产品意味着不断监控使用情况、集成新技术并不断满足新的用户需求。频繁的迭代需要代码足够高效以支持可观察性并且足够有弹性以适应变化。

那么什么是干净的代码呢？ DRY 首字母缩略词是一种常见的简写形式，但这只是一个起点。另一个可以给你一些更清晰方向的缩写词是SOLID 。正如您将在下面看到的，这也是一种特别适用于 Stoplight 组件库的方法：

单一责任原则：每个类都应该有单一的责任和单一的变更理由。这是函数式编程原则的面向对象版本，即函数应该“没有副作用”。 ”
开放封闭原则：一旦创建、测试和部署实体，新代码就可以扩展它，但不能修改它。使用接口创建原始类的变体有助于防止破坏性更改。
L iskov替换原则：替换子类的实例决不应该破坏父类的功能。子类必须继承父类的所有功能。这类似于开闭原则，但关注的是继承而不是随时间的变化。
接口隔离原则：遵守此原则有助于更轻松地遵守上述原则。从本质上讲，为父类提供更简单的接口类比为父类提供一个复杂的、过度指定的类更好。这允许更精确地根据客户需求定制功能组合，使客户应用程序更轻且更松散耦合。
依赖倒置原则：高层模块不应该依赖于低层模块；大多数依赖应该是抽象的。如果一个类依赖于另一个类，则该依赖关系应该是一个简单的抽象接口，该接口可以在将来根据需要进行扩展。

无论您严格遵守 SOLID 原则，还是只是努力遵循更简洁代码的一般实践，目的都是构建一个能够随着时间的推移而持续存在的 API 程序。当然有可能走得太远——批评者警告说，毫无疑问地使用“干净代码”实践会降低性能——这就是为什么我们强调需要正确看待原则。持久的产品需要满足真正的用户需求，但也需要经过精心设计以承受这些需求的变化。任何代码标准方法的目标都应该是弹性和灵活性，使未来的开发人员能够继续有效地为您的 API 消费者提供服务。

关注真实用户而非理想标准

在设计新的 API 程序时，没有绝对的最佳实践。正如我们上面所说，原则和实践应该服务于您的产品目标，而不是决定您的方法。那么您应该从哪里开始 API 设计过程呢？有两个主要选项，每个选项代表 API 的“相反”端：

API 设计优先方法首先定义最终用户需求，然后设计应用程序架构以最有效地满足这些需求。在这种方法中，API 端点根据您对开发人员如何与您的产品交互的了解，针对特定用例进行优化。
领域驱动设计从源数据开始，通常称为域。这些数据代表了您向 API 用户提供的专业知识，在这里开始您的设计过程可以让您将数据塑造成最准确、最有效地反映您的领域知识的模型。

一些纯粹主义者坚持认为，领域驱动方法是确保应用程序架构真正干净、没有潜在问题的依赖项并且随着时间的推移保持稳定的唯一方法。

正如您可能已经猜到的，我们将稍微推迟这一点。有些推理是合理的——在项目开始时建立共享的术语和定义是关键的一步，而创建准确、灵活的数据模型显然很重要，无论从哪里开始。但实现这些好处并不需要领域驱动的方法，而且如果您等待太长时间才评估 API 用户的需求，您可能会错过宝贵的信息。

API 用户需求势在必行

API 设计优先是一种与API 优先产品策略理念密切相关的开发方法。 API 优先首先将您的 API 视为一流产品，重点关注定义和满足消费者需求。设计优先将原则转化为实践，通过迭代定义 API 程序必须实现的结果并仔细描述它将如何交付这些结果的细节。开发过程首先确定用户需要的数据以及该数据的最佳形状，然后继续进行。

API 的设计思维播撒成功的种子

众所周知，我们坚信 API 优先的开发。该方法可以在整个设计和开发过程中创造更高的效率，并可以通过更少的试验和错误实现更持久的集成。由于您的团队首先考虑现实世界的用例，因此实际的安全问题从一开始就会引起关注。您可以尽早考虑移动使用情况和指标要求等因素，确保您的 API 设计满足发布时所需的技术规范。 API 是为恰好是开发人员的消费者提供的产品；设计 API 时要考虑到开发人员的需求，这是一项经过充分检验的业务策略。

不要让设计超越现实

尽管基于消费者需求进行设计很重要，但值得注意的是，API 优先的方法可能并不总是能产生组织良好的架构。 API 优先的方法可能会导致混乱的代码以及贫乏的领域模型。在某种程度上，这是因为从消费者端开始的设计流程往往关注端点和方法，并有很多拼凑在一起的事务脚本。开发人员构建控制器方法，将数据操纵成承诺端点所需的形状。此过程可能会生成大量具有不必要的复杂性和重复性的命令式代码。虽然 API 优先的设计并不一定会导致混乱，但防止混乱需要仔细的规划和协调。

声明您的领域专业知识

与 API 优先设计相比，领域驱动设计优先考虑内部资源的知识和功能。前提是，从准确有效地表示核心业务概念的数据架构开始，同时确保内部利益相关者的支持，您可以降低 API 的整体复杂性。

获得领域驱动设计的优势

理论上，DDD 将导致更多的声明性代码更容易阅读，从而更容易维护。在开发的初始阶段定义数据模型的形状、功能和关系可以增加生成干净、干燥代码的机会。当您最终进入创建控制器方法和 API 端点的阶段时，它们将由模型的形状决定，并且会以反映数据中表示的现实世界实体的方式自然地就位。

DDD 也有缺点

在实践中，对领域专业知识的狭隘关注可能会导致模型不够灵活，无法服务于现实世界的用例，特别是当焦点完全集中在内部上下文时。 “不要发布组织结构图”这句格言是一个警示，说明以领域为中心的团队倾向于创建反映他们的偏见而不是产品消费者需求的产品。这正式称为“康威定律” ，它会对产品质量产生严重后果。在整个 API 设计过程中需要有意识地努力避免陷阱。

DDD 也可能很慢，并且在开发的相当后期之前，您几乎无法根据 API 消费者的期望进行测试。如果您试图将新服务或产品快速推向市场，或者您的技术挑战超过了数据挑战，那么严格的领域驱动方法可能会成为障碍而不是帮助。

那么，当我们为新的 API 程序选择设计流程时，这会给我们带来什么影响呢？看来，虽然这两种方法都不完美，但都具有很大的潜在价值。

更好地构建您的后端

组件库允许您创建单个标准数据模型并在多个 API 之间共享它，因此您可以采用领域驱动设计中的关键概念：

将共享组件视为域模型，它代表您的业务需求的最重要的想法、知识和数据。您的组件库可以成为您的唯一事实来源。
使用屏蔽可以更灵活地重用不同 API 的模型，代表不同的子域。屏蔽基类的工作方式与扩展接口非常相似，这是 SOLID 设计的关键实践。
可视化您的设计模式并与工作区中的其他人共享，提高代码重用并使您的 API 更加干燥。
通过在 Stoplight 工作区中创建单独的 API，在有界上下文之间创建清晰的分隔，从而保持工作区中关键共享组件的一致性。
使用组件库中的命名约定来建立通用语言，轻松与技术和非技术利益相关者就领域需求进行沟通。

使用组件库可以帮助您实现 DDD 的优势：更简单的通信、提供更大灵活性的坚实基础，以及清楚数据形状在何处决定其他设计选择。

让您的 API 消费者成为焦点

API 设计优先的开发策略。这种方法带来了一些重要的好处：

精心设计、一致的数据模型并编入组件库中，有助于为您的 API 使用者创造改进的开发人员体验。
开发团队可以直接访问共享资源和工具，以促进协作和治理，提高工程效率并节省成本。
标准化数据模型有助于确保一致的数据隔离并减少可能的暴露点，从而提高 API 安全性。

组件库是一个单一工具，它提供了一个简单的可视化界面，用于与技术和非技术利益相关者共享模型，从而实现团队之间更好的协调。
将产品思维与支持 API 团队效率和代码质量的工具相结合，可以帮助您提高创新和增长。

组件库在整个产品生命周期中支持高质量的 API 程序。它们充当您的领域知识的存储库，使您能够以易于使用、可共享的格式记录内部资源和业务功能的专业知识。当您使用 API 设计优先策略时，由于组件库与 OpenAPI 工具集成，因此可以轻松地通过模拟将设计中的数据转移到开发中。无论从哪里开始，您都可以使用 DRY、SOLID 代码和一流的开发人员经验来构建 API。

有关 API 设计流程和工具的任何决策都应由您的独特需求和实际情况驱动。没有一个单一范例可以服务于每个 API 程序或开发团队。组件库的优点是它们不会强迫您采用教条方法——无论您采取什么策略，这个工具都可以帮助您实现精心构建的领域层和以用户为中心的设计过程的好处。

原文链接：Build Cleaner, DRYer APIs with Component Libraries