到目前为止，本书提供了一种以六边形架构风格构建 Web 应用程序的固执己见的方法。从组织代码到走捷径，我们已经回答了这种架构风格所面临的许多问题。
本书中的一些答案可以应用于传统的分层架构风格。有些答案只能通过以领域为中心的方法来实现，就像本书中提出的方法一样。有些答案你甚至可能不同意，因为它们在你的经验中不起作用。
然而，我们想要答案的最后一个问题是：我们什么时候应该真正使用六边形架构风格？我们什么时候应该坚持传统的分层风格（或任何其他风格）？
领域为王
在前面的章节中应该已经很明显，六边形架构风格的主要特征是我们可以在开发领域代码时免受诸如持久性问题和对外部系统的依赖等干扰。
不受外部影响的不断发展的领域代码是六边形架构风格最重要的一个论据。
这就是为什么这种架构风格非常适合 DDD 实践。显而易见的是，在 DDD 中，领域驱动着开发。如果我们不必同时考虑持久性问题和其他技术方面，我们就可以最好地推理该领域。
我甚至可以说，以领域为中心的架构风格（例如六边形风格）是 DDD 的推动者。如果没有将领域置于事物中心的架构，没有反转对领域代码的依赖关系，我们就没有机会真正进行领域驱动设计。设计总是受到其他因素的驱动。
因此，作为是否使用本书中介绍的架构风格的第一个指标：如果域代码不是应用程序中最重要的事情，那么您可能不需要这种架构风格。
经验为王
我们是习惯的生物，习惯可以帮助我们自动做出决策，这样我们就不必花时间在上面。如果有一头狮子向我们跑来，我们就跑。如果我们构建一个新的 Web 应用程序，我们会使用分层架构风格。我们过去经常这样做，以至于它已经成为一种习惯。
我并不是说这一定是一个错误的决定。习惯有助于做出正确的决定，也有助于做出错误的决定。我是说，我们正在做我们有经验的事情。我们对过去所做的事情感到满意，那么我们为什么要改变任何事情呢？
因此，对架构风格做出明智决定的唯一方法是拥有不同架构风格的经验。如果您不确定六边形架构风格，请在您当前正在构建的应用程序的一个小模块上尝试一下。习惯这些概念，应用本书中的想法，修改它们，并添加你自己的想法来开发你喜欢的风格。
这种经验可以指导您的下一个架构决策。
这取决于...
我很乐意提供一系列多项选择题来决定架构风格，就像所有“你是哪种性格类型？”和“你是什么样的狗？”社交媒体上经常流传的测试。
但这并不那么容易。对于选择哪种架构风格这个问题，我的回答仍然是专业顾问常说的“这取决于……”。这取决于要构建的软件类型。这取决于域代码的作用。这取决于团队的经验。最后，这取决于对决定的适应程度。
然而，我希望这本书能够提供一些灵感来帮助解决架构问题。如果您有一个关于架构决策的故事，无论是六边形架构或是其它，我很想听听。
