You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a discussion about opening up the ports and adapters pattern to a more abstract and modify-able system.
When I was working through the process of documenting how one might go about creating their own ports and then building their own adapters, it occurred to me, that the current design would be for the hyper63 project to incorporate the port into the core. And then the port is specified by a string in the configuration
I think this kind of control may be unnecessary, we could simply allow developers to import the port of their choosing, then the core would wrap the adapter in the port to validate it. A config file might look like this:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a discussion about opening up the ports and adapters pattern to a more abstract and modify-able system.
When I was working through the process of documenting how one might go about creating their own ports and then building their own adapters, it occurred to me, that the current design would be for the hyper63 project to incorporate the port into the core. And then the port is specified by a string in the configuration
Then another thought occurred to me, it might be worth entertaining the idea to make the API a generic pattern
In the
app-express
it could implement a pattern like thisAnd that endpoint would connect the request to the appropriately loaded
port
andmethod
This would keep the focus of the project on the glue code of the client -> app -> ports -> adapters
And observability would be baked in at the app level or a middleware mod.
Beta Was this translation helpful? Give feedback.
All reactions