1. 概述
六边形架构(Hexagonal Architecture), 又叫做端口适配器模式(Ports & Adapters)，是由 Alistair Cockburn2005年提出的。
意图
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
允许应用程序同样由用户，程序，自动化测试或批处理脚本驱动，并与最终的运行时设备和数据库隔离开发和测试。
英语好的，可以看一下下面原文（我英语极差，在翻译下阅读的，可能有误，忘指出）：
动机
为什么会出现六边形架构？
多年来，软件应用程序的最大缺陷之一是业务逻辑渗透到用户界面代码中。 这引起的问题有三个方面：
-
首先，无法使用自动化测试套件对系统进行完整的测试，因为需要测试的部分逻辑依赖于经常变化的视觉细节，例如字段大小和按钮位置。
-
出于完全相同的原因，不可能从人工驱动的系统转换为批处理运行的系统。
-
出于同样的原因，当程序耦合度逐渐增高时，很难或不可能允许该程序被另一个程序驱动。
在许多组织中反复尝试的解决方案是在体系结构中创建一个新层，并保证这次确实没有将业务逻辑放入新层中。 但是，由于没有机制来检测何时发生违反该承诺的情况，该组织发现，几年后，新层被业务逻辑弄得乱七八糟，旧问题又出现了。
我们知道，电脑与周边设备是通过端口与驱动（适配器）交互的，且只需要有相应的驱动，端口可以和不同的设备进行交互。六边形架构关注的是“外部”和“内部”的差别，内部业务逻辑（Application)与外设（APP,WEB，数据库等）完全隔离，仅通过Adapter 进行交互。
2. 架构思想
六边形架构是基于三个原则和技术的：
- Explicitly separate Application, Domain, and Infrastructure
- Dependencies are going from Application and Infrastructure to the Domain
- We isolate the boundaries by using Ports and Adapters
- 明确区分应用程序，领域和基础结构三个层
- 依赖关系是从应用程序和基础结构再到领域
- 使用端口和适配器隔离它们的边界
第一个原则：分层
应用程序端(Application)：这是用户或外部程序将与应用程序进行交互的一面。API 的 HTTP 路由，JSON 序列化都在这里，有点类似于 MVC 的 controller 层。
领域(Domain)：左右两端隔离的部分，它包含所有涉及并实现业务逻辑的代码。
基础架构(Infrastructure)：在这里我们可以找到您的应用程序需要什么，它可以驱动什么工作。它包含基本的基础结构详细信息，例如与数据库交互的代码，对文件系统的调用或处理对您依赖的其他应用程序的 HTTP 调用的代码。
第二个原则：依赖关系进入域
简单的说，一切都依赖于 Domain，而 Domain 不依赖于任何东西。Alistair Cockburn 坚持内部和外部之间的这种划分，这比应用程序和基础结构之间的差异更具结构性，可以解决最初的问题。
第三个原则：边界与接口隔离
总而言之，应用程序代码通过业务代码中定义的接口（此处为 IRequestVerses）驱动业务代码。商业代码通过同样在商业代码（IObtainPoems）中定义的接口来驱动基础架构。这些接口充当**内部和外部之间的显式绝缘体**。
简单的说，就是应用程序和基础架构都直接依赖业务代码提供的接口直接驱动，我们不需要关注业务代码是怎么实现的。
想要深入了解三个规则，请参考：Hexagonal Architecture: three principles and an implementation example
3. Metaphor
将这种架构模式比喻成端口适配器或者六边形。
Adapter起什么作用
它负责将与外设交互的数据（包括命令、query）转化为 Application 可以理解的信息(业务module)，并通过内部系统提供的接口进行业务逻辑的处理。
Port
对于软件系统来讲，port 上端口协议的体现就是 api,即业务系统对外暴露的接口，一个端口可以有多个适配器。比如一个系统提供产口的信息的展示，这时候该信息可能需要在 app,web 或者作为远程服务对外提供产品信息，这时候由 Application 是提供一个 query 接口，并返回一个对象，至于要将其转换成 app,web 或者远程服务 json 格式，则由 adapter 来完成。
4. Hexagonal Architecture Example
代码示例：Hexagonal Architecture Example
小结&参考资料
小结
现在的设计模式大部分是 MVC 模式，应用层、业务层、持久层，使用也确实很容易上手，但当项目逐渐迭代时，有些业务代码对于分层模糊不清，只能将代码放入新加的层，但这样弊端也逐渐愈加明显，模块相互间耦合逐渐增加，对于代码维护和迭代更加复杂。这时就需要我们有更清晰简单的架构来开发。除了六边形架构，还有 Clean architecture。有兴趣的小伙伴自行了解。
