Both the user-side and the server-side problems actually are caused by the same error in design and programming — the entanglement between the business logic and the interaction with external entities.
The asymmetry to exploit is not that between ‘’left’’ and ‘’right’’ sides of the application but between ‘’inside’’ and ‘’outside’’ of the application.
The rule to obey is that code pertaining to the ‘’inside’’ part should not leak into the ‘’outside’’ part.
The hexagon is intended to visually highlight inside-outside asymmetry and the similar nature of ports, to get away from the one-dimensional layered picture and all that evokes, and
the presence of a defined number of different ports – two, three, or four (four is most I have encountered to date).
The ports and adapters pattern is deliberately written pretending that all ports are fundamentally similar. That pretense is useful at the architectural level. In implementation, ports and adapters show up in two flavors, which I’ll call ‘’primary’’ and ‘’secondary’’, for soon-to-be-obvious reasons. They could be also called ‘’driving’’ adapters and ‘’driven’’ adapters.
A ‘’primary actor’’ is an actor that drives the application (takes it out of quiescent state to perform one of its advertised functions). A ‘’secondary actor’’ is one that the application drives, either to get answers from or to merely notify. The distinction between ‘’primary ‘’and’’ secondary ‘’lies in who triggers or is in charge of the conversation.
The ‘’Design Patterns’’ book contains a description of the generic ‘’Adapter’’ pattern: “Convert the interface of a class into another interace clients expect.”
“Patterns for Generating a Layered Architecture”, Barry Rubel describes a pattern about
The difference between a primary and secondary actor lies only in who initiates the conversation. A primary actor knows about and initiates the conversation with the system or application; for a secondary actor, it is the system or application that knows about and initiates the discussion with the other. That is actually the only difference between the two, in use case land.
In implementation, that difference matters: Whomever will initiate the conversation must be handed the handle for the other.
In the case of primary actor ports, the macro constructor will pass to the UI, test framework, or driver the handle for the app and say, “Go talk to that”. The primary actor will call into the app, and the app will probably never know who called it. (That is normal for recipients of a call).
In stark contrast, for secondary actor ports, the macro constructor will pass to the UI, test framework, or driver the handle for the secondary actor to be used, that will get passed in as a parameter to the app, and the app will now know who/what is the recipient of the outgoing call. (This is again normal for sending out a call).