> - First, the system can’t neatly be tested with automated test suites because part of the logic needing to be tested is dependent on oft-changing visual details such as field size and button placement;
> - For the exact same reason, it becomes impossible to shift from a human-driven use of the system to a batch-run system;
> - For still the same reason, it becomes difficult or impossible to allow the program to be driven by another program when that becomes attractive.
Is any of the above a real pain in the project that you are building in 2022?
I very much doubt it is. And if it's not, then introducing such an architecture will bring more harm than benefit.
These architectures were introduced around 20 years ago to address technical shortcomings of enterprise systems at that time.
Quoting the original article on Hexagonal architecture (https://web.archive.org/web/20090327032122/http://alistair.c...), the motivation was to address those 3 problems:
> - First, the system can’t neatly be tested with automated test suites because part of the logic needing to be tested is dependent on oft-changing visual details such as field size and button placement;
> - For the exact same reason, it becomes impossible to shift from a human-driven use of the system to a batch-run system;
> - For still the same reason, it becomes difficult or impossible to allow the program to be driven by another program when that becomes attractive.
Is any of the above a real pain in the project that you are building in 2022?
I very much doubt it is. And if it's not, then introducing such an architecture will bring more harm than benefit.
There were some interesting discussions on that topic lead by Martin Fowler few years ago: https://www.martinfowler.com/articles/badri-hexagonal/