Clarification on Port and Adapters / Hexagonal architecture

Question

I have read Alistair's article on Hexagonal pattern and gone through other resources related to this (Alistair's videos, Short description of Ports & Adapters).

I understand the general idea of Hexagonal architecture and what are the advantages it brings to modern application development. But still, I have some confusion related to the actual implementation of Ports and Adapters.

Question 1:

From Alistair's article,

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 Separates ports into two categories which are driving ports and driven ports. Driving ports control the application (GUI) and Driven port controlled by the application (database).

So if the driving port should only contain control APIs then how the Adapters at driving port side will get the event notifications. For example, in the below diagram I have two driving adapters which control the application but it also needs information from the application to send it back to other application connected to that adapter.

Interface IDriving {

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

//Events send from application
statusInfoEvent();
}

You could consider the statusInfoEvent() as a Qt signal emitted from the application side or some common observable pattern. Is it a violation of Hexagonal pattern to keep the incoming and outgoing traffic API at the same Interface (port) ? and most importantly the implementation is done inside the hexagon as it's a driving port.

Question 2:

Have ever seen or worked on Hexagonal pattern like below.

Consider the driven adapter of service 1 as some storage medium, service 1 can push and pull information to/from it. These two adapters of service 1 (both driving and driven) is implemented inside service 2 (at least in project level), Now service 2 receive some data from it's driving adapter (web or dbus) and update the storage medium of service 1 driven adapter, also it needs to notify the updation to service 1 through the driving adapter.

Is it possible to do this in a better way?

Answer 1

Question 1:

A driver adapter starts the conversation with the hexagon, just that. But it doesnt have anything to do with the data flow, i.e., the driver port can return data to the driver adapter.

Question 2:

The drawing doesnt have any sense to me, could you please try to express it in another way?

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

If you wanna read more about hexagonal architecture:

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