本书的目标
如果你阅读了这本书，那么你就会关心你正在构建的软件的架构。你希望你的软件不仅能满足客户的显性需求，还能满足隐性的可维护性需求以及你自己对结构和美观的要求。
满足这些要求很困难，因为软件项目（或一般项目）通常不会按计划进行。项目团队的经理们都在制定最后期限，外部合作伙伴构建的 API 与他们承诺的不同，我们所依赖的软件产品也没有按预期工作。
然后是我们自己的软件架构，一开始真是太好了，一切都清晰而美丽，但最后期限迫使我们走捷径。现在，架构只剩下走捷径了，交付新功能需要越来越长的时间。
我们的快捷方式驱动的架构使得我们很难对由于外部合作伙伴搞砸而必须更改的 API 做出反应。让我们的项目经理与该合作伙伴进行战斗，告诉他们交付我们商定的 API 似乎更容易。
现在我们已经放弃了对局势的所有控制。
很可能会发生以下情况之一：
• 项目经理的实力不足以赢得与外部合作伙伴的战斗。
• 外部合作伙伴发现 API 规范中的漏洞，证明它们是正确的。
• 外部合作伙伴还需要 <在此处输入数字> 个月来修复 API。
所有这些都会导致相同的最终结果：我们必须自己解决它，因为最后期限迫在眉睫，我们添加了另一个快捷方式。
本书不让外部因素控制我们软件架构的状态，而是采取我们自己控制的立场。我们通过创建一个使软件变得柔软的架构来获得这种控制，例如“灵活”、“可扩展”和“适应性强”。这样的架构会让我们很容易对外部因素做出反应，并承受我们背部的很大压力。
我写这本书是因为我对以领域为中心的架构风格，例如 Robert C. Martin 的“整洁架构” 和 Alistair Cockburn的“六边形架构”的实用性感到失望 。许多书籍或在线资源解释了有价值的概念，但没有解释我们如何实际实施它们。
这可能是因为实现这种架构的方法不止一种。
在这本书中，我试图通过提供有关以六边形架构风格创建 Web 应用程序的实践代码讨论来填补这一空白。为了实现这一目标，本书中讨论的代码示例和概念提供了如何实现六边形架构的一种解释。当然还有其他的解释，我并不认为我的解释是适用于所有情况的灵丹妙药。
然而，我当然希望你会发现本书中的一些概念足够有用，可以将它们纳入你自己的工具箱中。
谁应该读这本书
本书面向参与创建 Web 应用程序的所有经验级别的软件开发人员。
作为初级开发人员，你将学习如何以干净且可维护的方式设计软件模块和完成应用程序。
你还将了解何时应用某种技术的一些论据。然而，为了充分利用本书的内容，你过去应该参与过 Web 应用程序的构建。
如果你是一位经验丰富的开发人员，你会喜欢将书中的概念与你自己的做事方式进行比较，并将点滴融入到你自己的软件开发风格中。
本书中的代码示例是用 Java 编写的，但所有讨论同样适用于其他面向对象的编程语言。如果你不是 Java 程序员，但可以阅读其他语言的面向对象代码，那么你仍然没问题。在我们需要一些 Java 或框架细节的少数地方，我们将对其进行解释。
示例应用程序为了在整本书中重复出现一个主题，大多数代码示例都使用了在线转账的示例 Web 应用程序的代码。我们将其称为“BuckPal”。
BuckPal 应用程序允许用户注册帐户、在帐户之间转账以及查看帐户上的活动（存款和取款）。
无论如何，我都不是银行专家，所以请不要根据法律或功能的正确性来判断示例代码。而是根据结构和可维护性来判断它。
软件工程书籍和在线资源中使用的示例应用程序的缺点是它们太简单，无法突出我们每天都在努力解决的现实问题。另一方面，示例应用程序不能太复杂，以便能够传输所讨论的概念。
当我们在本书的其余部分讨论 BuckPal 应用程序的用例时，我希望在“太简单”和“太复杂”之间找到平衡。
示例应用程序的代码可以在 github 上找到。
关于代码示例的注释
本书中的代码示例是用 Java 编写的。即使作为 Java 迷，我也承认 Java 是一种非常冗长的编程语言。由于我不希望你被代码示例中的样板代码分散注意力，因此我决定将其保留。为了使代码仍然有效，我在代码中包含了 Lombok 注解，它将自动生成一些样板代码：
• @Getter 注释将为注释字段自动生成 getter 方法，或者如果在类上使用，则在该类的所有私有字段上自动生成 getter 方法，
• @RequiredArgsConstructor 注解将自动生成一个带有参数的构造函数来初始化类的所有私有最终字段，
• @NoArgsConstructor 注释将自动生成一个无参数（默认）构造函数。
