君子如兰

到目前为止，本书提供了一种以六边形架构风格构建 Web 应用程序的固执己见的方法。从组织代码到走捷径，我们已经回答了这种架构风格所面临的许多问题。 本书中的一些答案可以应用于传统的分层架构风格。有些答

在本书的序言中，我讲过这样一个事实：我们总是感觉被迫走捷径，积累了一大堆我们永远没有机会偿还的技术债务。 为了防止走捷径，我们必须能够识别它们，因此，本章的目标是提高人们对一些潜在捷径的认识并讨论其效

我们在前面的章节中讨论了很多关于架构的内容，有一个目标架构来指导我们决定如何编写代码以及将代码放在哪里，感觉很好。 然而，在每个大型软件项目中，架构往往会随着时间的推移而被侵蚀。层之间的界限减弱，代码

现在我们已经实现了一些用例、Web 适配器和持久性适配器，我们需要将它们组装成一个可工作的应用程序。正如第 3 章“组织代码”中所讨论的，我们依靠依赖注入机制来实例化我们的类并在启动时将它们连接在一起

在前面的章节中，我们讨论了 Web、应用程序、域和持久层以及每个层对实现用例的贡献。 然而，我们几乎没有触及每层模型之间映射的可怕且无处不在的主题。我敢打赌，您曾经 讨论过是否在两个层中使用相同的模型

在我目睹的许多项目中，自动化测试是一个谜。每个人都按照他或她认为合适的方式编写测试，因为这是 wiki 中记录的一些尘封的规则所要求的，但没有人可以回答有关团队测试策略的有针对性的问题。 本章提供了六

在第一章中，我对传统的分层架构进行了全面剖析，并声称它支持“数据库驱动设计”，因为最终一切都取决于持久层。在本章中，我们将了解如何使持久层成为应用层的插件以反转这种依赖性。 依赖倒置 我们将讨论为应用

如今，大多数应用程序都有某种 Web 界面 - 要么是我们可以通过 Web 浏览器与之交互的 UI，要么是其他系统可以调用以与我们的应用程序交互的 HTTP API。 在我们的目标架构中，与外界的所有

最后让我们看看如何在实际代码中实现我们所讨论的架构。 由于应用层、Web 层和持久层在我们的架构中耦合度非常松散，因此我们可以完全自由地按照我们认为合适的方式对域代码进行建模。我们可以做 DDD，我们