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

Question

我读过 Alistair 的 article在六边形图案上并浏览了与此相关的其他资源(Alistair's videos，Short description of Ports & Adapters)。

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

问题 1:

来自 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 保持在同一接口(interface)(端口)是否违反六边形模式？最重要的是，实现是在六边形内部完成的，因为它是一个驱动端口。

问题 2:

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

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

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

Answer 1

问题一:

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

问题二:

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

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

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

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