本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 质量源于设计
<a name="improve-software-quality"></a>

采用六边形架构有助于从项目一开始就提高代码库的质量。重要的是要建立一个从一开始就帮助您满足预期质量要求的流程，同时又不会减慢开发过程。

## 本地化更改和更高的可读性
<a name="readability"></a>

使用六边形架构方法，开发人员可以在不影响其他类或组件的情况下更改一个类或组件中的代码。这种设计促进了已开发组件的凝聚力。通过将域与适配器解耦并使用众所周知的接口，可以提高代码的可读性。识别问题和极端案例变得更加容易。

这种方法还可以促进开发过程中的代码审查，并限制引入未被发现的更改或技术债务。

## 首先测试业务逻辑
<a name="logic"></a>

本地测试可以通过向项目引入 end-to-end、集成和单元测试来完成。 End-to-end测试涵盖整个传入请求生命周期。他们通常会调用应用程序入口点并进行测试，以查看其是否已满足业务需求。每个软件项目应至少有一个使用已知输入并产生预期输出的测试方案。但是，添加更多的极端情况可能会变得复杂，因为必须将每个测试配置为通过入口点（例如，通过 REST API 或队列）发送请求，遍历业务操作所需的所有集成点，然后断言结果。为测试场景设置环境并断言结果可能需要开发人员花费大量时间。

在六角形架构中，您可以隔离测试业务逻辑，并使用集成测试来测试辅助适配器。你可以在业务逻辑测试中使用模拟或假适配器。您还可以将业务用例测试与域模型的单元测试相结合，以保持高覆盖率和低耦合。作为一种好的做法，集成测试不应验证业务逻辑。相反，他们应该验证辅助适配器是否正确调用了外部服务。

理想情况下，您可以使用测试驱动开发 (TDD)，并在开发之初通过适当的测试开始定义领域实体或业务用例。首先编写测试可以帮助您创建域所需接口的模拟实现。当测试成功并且满足域逻辑规则时，您可以实现实际的适配器并将软件部署到测试环境。此时，您对域逻辑的实现可能并不理想。然后，您可以通过引入设计模式或重新排列一般代码来重构现有架构以对其进行改进。通过使用这种方法，您可以避免引入回归错误，并且可以随着项目的发展改进架构。通过将这种方法与您在持续集成过程中运行的自动测试相结合，可以在潜在错误投入生产之前减少其数量。

如果您使用无服务器部署，则可以在您的 AWS 账户中快速配置应用程序实例以进行手动集成和 end-to-end测试。完成这些实施步骤后，我们建议您对推送到存储库的每个新更改进行自动测试。

## 可维护性
<a name="maintainability"></a>

可维护性是指操作和监控应用程序，以确保其满足所有要求并最大限度地降低系统故障的可能性。要使系统可运行，必须使其适应未来的流量或运营需求。您还必须确保它可用且易于部署，同时尽量减少或不影响客户端。

要了解系统的当前和历史状态，必须使其可观察。为此，您可以提供特定的指标、日志和跟踪，操作员可以使用这些指标、日志和跟踪来确保系统按预期运行并跟踪错误。这些机制还应允许操作员进行根本原因分析，而不必登录机器并阅读代码。

六边形架构旨在提高 Web 应用程序的可维护性，从而减少代码所需的总体工作量。通过分离模块、本地化更改以及将应用程序业务逻辑与适配器实现分离，您可以生成指标和日志，帮助操作员深入了解系统并了解对主适配器或辅助适配器所做的特定更改的范围。