对端口和适配器/六边形架构的说明

Question

我读过 Alistair 的 article on Hexagonal pattern and gone through other resources related to this (Alistair's videos, Short description of Ports & Adapters)。

我了解六边形架构的总体思路以及它为现代应用程序开发带来的优势。但是，我仍然对端口和适配器的实际实现有些困惑。

问题一：

来自 Alistair 的文章，

In an implementation, ports and adapters show up in two flavours, which I’ll call primary and secondary, for soon-to-be-obvious reasons. They could be also called driving adapters and driven adapters.

He 将端口分为驱动端口和从动端口两类。驱动端口控制应用程序（GUI）和驱动端口由应用程序（数据库）控制。

因此，如果驱动端口应仅包含控件 API，那么驱动端口侧的适配器将如何获取事件通知。例如，在下图中，我有两个控制应用程序的驱动适配器，但它也需要应用程序的信息将其发送回连接到该适配器的其他应用程序。

Interface IDriving {

//control application
startService();
stopService();

//Events send from application
statusInfoEvent();
}

您可以将 statusInfoEvent() 视为从应用程序端发出的 Qt 信号或一些常见的可观察模式。 将传入和传出流量 API 保持在同一接口（端口）是否违反六边形模式？ 最重要的是，实施是在六边形内部完成的，因为它是驱动端口.

问题二：

曾见过或研究过如下所示的六角形图案。

将服务1的驱动适配器看做是某种存储介质，服务1可以向它推送和拉取信息to/from。服务 1 的这两个适配器（驱动和驱动）在服务 2 内部实现（至少在项目级别），现在服务 2 从它的驱动适配器（web 或 dbus）接收一些数据并更新服务 1 驱动适配器的存储介质,还需要通过驱动适配器通知服务1更新

有没有可能以更好的方式做到这一点？

Answer 1

问题 1：

驱动程序适配器开始与六边形对话，仅此而已。但它与数据流没有任何关系，即驱动程序端口可以return数据到驱动程序适配器。

问题 2：

画的我看不懂，能不能换个方式表达一下？

============================

如果您想阅读更多关于六边形建筑的信息：

https://jmgarridopaz.github.io/content/articles.html

对端口和适配器/六边形架构的说明

Clarification on Port and Adapters / Hexagonal architecture

architecture

hexagonal-architecture