这是一篇关于在 Rust 中实现六边形架构的指南，包含多个部分，主要内容如下：

• 引言：介绍六边形架构，它能解决 Rust 应用中的一些问题，提高代码的可维护性、测试覆盖率和扩展性。建议先阅读《Rust Newtypes 终极指南》，并将本指南分部分发布，每部分发布后会有练习。示例应用是一个带有axumWeb 服务器的博客引擎。

• 不良 Rust 应用的剖析：

  • 展示了一个常见的“非常糟糕的应用”，其main.rs函数负责配置 HTTP 中间件、数据库连接池等，代码耦合度高，难以维护和扩展。
  • 分析了硬依赖和六边形架构的关系，指出像 Tokio 这样的依赖是必要的，而 HTTP 包、数据库客户端等依赖则应抽象化。

• 分离关注点的 Rust 方式：

  • 开始向六边形架构过渡，将“非常糟糕的应用”中的create_author处理程序从直接操作 SQL 数据库转移到抽象的存储库概念，定义了AuthorRepository特质。
  • 介绍了领域模型，如CreateAuthorRequest、Author和CreateAuthorError，它们是业务逻辑接受的数据的规范表示，通过新类型定义实现了关注点分离和可扩展性。
  • 讨论了错误类型和六边形架构，CreateAuthorError定义了协调适配器操作时的失败情况，通过anyhow::Error进行错误处理和传播。
  • 实现了AuthorRepository，将与 SQL 数据库的交互代码封装在Sqlite类型中，实现了事务管理，并处理了数据库错误。
  • 解决了异步和Send边界问题，使AuthorRepository成为异步特质，并确保其可发送性。
  • 展示了从“非常糟糕的应用”到“仅仅糟糕的应用”的转变，通过AuthorRepository抽象化create_author处理程序，提高了代码的可测试性和可维护性。
  • 介绍了使用注入存储库进行 HTTP 处理程序测试的方法，通过模拟存储库实现单元测试。

• Service，六边形架构的核心：

  • 引入Service特质，它封装了业务逻辑的调用，将数据库操作、通知发送和指标收集等与处理程序分离，提高了代码的可测试性和可维护性。
  • 解释了main函数的职责是启动和关闭应用，通过组合域特质的实现来创建AuthorService，并将其注入到 HTTP 服务器中。
  • 讨论了为什么选择六边形架构，它类似于最初由 Alistair Cockburn 提出的六边形架构，其中适配器围绕着业务域，保护业务域免受外部变化的影响。
  • 介绍了如何选择正确的领域边界，包括根据业务功能和原子操作来确定领域的范围，以及在大型应用中如何处理主记录和认证授权。
  • 提供了一个用于六边形架构的 Rust 项目模板，展示了如何组织代码模块和文件结构。

• Rust 中六边形架构的权衡：

  • 讨论了六边形架构的优缺点，它高度解耦，提高了测试覆盖率和代码组织性，但也增加了代码量和学习成本，对于一些小型、高性能或个人项目可能不是最优选择。
  • 分析了六边形架构在不同类型项目中的适用性，如对于 solo 开发者和个人项目，抽象可能会使代码更脆弱；对于业务逻辑简单的应用，可能不需要端口和适配器；对于初创企业，六边形架构有助于从一开始就进行全面的测试和扩展；对于大型团队的大型单体应用，先将其重构为六边形单体应用再迁移到微服务可以降低难度；对于大型企业的新代码库，六边形架构可以提供良好的项目结构和测试覆盖。
• 高级六边形架构在 Rust 中：本部分尚未发布。

总之，六边形架构是一种强大的软件架构模式，通过将业务逻辑与外部依赖分离，提高了 Rust 应用的可维护性、可测试性和可扩展性，但在使用时需要根据项目的特点进行权衡和选择。