0

I'm look for some guidance or best practise for how to configure and structure an Application which conforms to Hexagonal architecture that supports multiple (driver) adapters simultaneously.

My API / Application Layer / Ports represent the boundary of the Application. I am now writing the driver adapters, with the goal that the application supports both a console / CLI adapter and REST adapter in tandem.

Does anyone have any thoughts on approaches to the Main Component that configures and wires the application together?

  • A single Main Component that configures the full application: including all primary adapters. Along with loading the application configuration. In this case it would start the REST services and start the CLI console app.

  • A separate Main Component for each type of Primary adapter. ie. One for the REST application. One for the CLI / Console application. My concern is will result in a lot of duplication for configuring the Application within the boundary (ie. the API Services, Repositories, etc etc).

  • Follow the above approach but extract the common configuration / wiring into a shared class.

If anyone has any examples they could share that would be interesting to see.

Cheers,

Steve

Steven
  • 633
  • 4
  • 13

1 Answers1

1

This is an interesting question.

From my point of view, trying to be faithful to the pattern explained by its author, although it would also be posible to run more than one driver adapter for one driver port, the "app as a whole" (let's call it system, since the app is the hexagon) is an instance of a driver adapter running on each driver port of the hexagon, and a driven adapter implementing each driven port.

The configuration of the system is the adapter to select for each port. When you run the main component, you have to specify which adapter you want for every port.

That said, I studied two approaches in order to run the system:

(1) To have an additional component (name it main component, composition root, startup, init, or whatever you want) that instantiates the driven adapters and the hexagon, and finally instantiate the driver adapters and run them. This way, the system architecture would look like an app container in the driver side, and a plugin architecture in the driven side.

(2) To run each driver adapter on its own. It is the driver adapter that starts the game, asking the hexagon for a driver port instance, and the hexagon would ask every driven port for a driven adapter instance.

So to your question about the main component in your example, according to my approach (1), I would have two hexagon instances running, but you could have just one, I don't see any problem on that.

I wrote a theorical article about hexagonal architecture at https://softwarecampament.wordpress.com/portsadapters/ , and now I'm working on an article about how to implement hexagonal architecture, and a code example.

choquero70
  • 3,332
  • 2
  • 24
  • 40