Does it work if you think about the database as the database solution rather than the database itself? In one solution the hexagon at that level contains Postgres. In the other it contains DynamoDB and CloudSearch. The ports exposed at the boundary of the hexagon would then be the same. I'm still getting my head round this topic so feel free to come back at me if this is a gross simplification of what you are highlighting.
I wondered about that after I wrote the post, but that also falls down if I want to then replace CloudSearch with Elastisearch but not replace DynamoDB. Then I'm reworking a part of one adapter and not just swapping it out for a different one.
You could see your 'big' hexagon as having within it two smaller hexagons that represent how that particular solution is composed.
One for cloud search and one for DynamoDB. Which I think is okay if neither DynamoDB or CloudSearch are used independently anywhere else. The ports between CloudSearch and DynamoDB are on the internal faces as they don't affect the larger solution. Things that are used outside are on the external faces.
Then you could still swap out one of those smaller hexagons for one that supported the same combination of ports.
I don't know myself if that deviates too far from the spirit of hexagonal architecture though.
Graham, I agree that some parts of infrastructure define the ports. Anyway, it is not the infrastructure itself, but your requirements. You can always abstract everything, as Mark pointed out you can use a composed adapter. But on the other hand, performance would be negatively affected or you would need extra ceremony (and code) to do what you want.
I can mention another point on the same example of changing between Postgres and Mongo. Postgres will have integer autogenerated IDs, and Mongo will only use UUIDs. This is a problem when you define repositories in a typed language (like Java) and use something as Repository (as suggested in Spring or commonly implemented in DDD examples). You can always use another field as a real primary key in the database but this would impact the performance. So finally you need to choose what is going to be abstracted. That's the developer works, to choose between trade-offs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Does it work if you think about the database as the database solution rather than the database itself? In one solution the hexagon at that level contains Postgres. In the other it contains DynamoDB and CloudSearch. The ports exposed at the boundary of the hexagon would then be the same. I'm still getting my head round this topic so feel free to come back at me if this is a gross simplification of what you are highlighting.
I wondered about that after I wrote the post, but that also falls down if I want to then replace CloudSearch with Elastisearch but not replace DynamoDB. Then I'm reworking a part of one adapter and not just swapping it out for a different one.
Yes, I see what you mean...
You could see your 'big' hexagon as having within it two smaller hexagons that represent how that particular solution is composed.
One for cloud search and one for DynamoDB. Which I think is okay if neither DynamoDB or CloudSearch are used independently anywhere else. The ports between CloudSearch and DynamoDB are on the internal faces as they don't affect the larger solution. Things that are used outside are on the external faces.
Then you could still swap out one of those smaller hexagons for one that supported the same combination of ports.
I don't know myself if that deviates too far from the spirit of hexagonal architecture though.
Hmm - That's interesting.
So you end up with:
It works. It feels quite complicated, but it works. :)
Graham, I agree that some parts of infrastructure define the ports. Anyway, it is not the infrastructure itself, but your requirements. You can always abstract everything, as Mark pointed out you can use a composed adapter. But on the other hand, performance would be negatively affected or you would need extra ceremony (and code) to do what you want.
I can mention another point on the same example of changing between Postgres and Mongo. Postgres will have integer autogenerated IDs, and Mongo will only use UUIDs. This is a problem when you define repositories in a typed language (like Java) and use something as Repository (as suggested in Spring or commonly implemented in DDD examples). You can always use another field as a real primary key in the database but this would impact the performance. So finally you need to choose what is going to be abstracted. That's the developer works, to choose between trade-offs.