TL;DR: You’ll discover the advantages of Hexagonal Architecture in:
Simplifying Your Code: Transforming intricate coding and testing efforts int...
For further actions, you may consider blocking this person and/or reporting abuse
As a junior developer navigating the world of web development, you found solace in Hexagonal Architecture, a concept that your tech lead introduced to shield the domain logic from real-world complexities. Reflecting on your experience, you highlighted the advantages of Hexagonal Architecture, including simplified code, enhanced real-world insights, and seamless adaptability for new features. Could you delve deeper into how Hexagonal Architecture promotes test-driven development (TDD) and simplifies the testing process, as evidenced by your practical examples? Additionally, could you share any challenges you faced as a junior developer while implementing Hexagonal Architecture, particularly in terms of terminology and the extensive use of various patterns, and how you overcame these hurdles? FOLLOW BACK FOR INSIGHTFUL DISCUSSIONS
Thanks for the comment, and the clear summary!
Regarding testing, especially for domain features, we usually test by setting the input thanks to mocks of the result of the input interface, and only using method of the interface that is implemented by the class in question (outputs). We internally refer to it to blackbox testing (I don't know if the term is appropriate), as we don't care what happens inside the method, just that the outputs matches the one expected
Therefore, even with stubs of the methods implemented by the class, we can write the tests, so as to test early and fail early.
Regarding difficulties, as for terminology, it was mostly related to naming conventions, as for example, what had classes named "Service" inside and outside the domain, sometimes what was inside the domain was called "Service", sometimes "Usecase"... Since it was different from the terminology I was introduced to (which was very theoretical, I was quite lost with what went where.
For patterns, it was for example that at times there were several way to actually "implement" interfaces (as with the example I gave), or that sometimes we didn't even go into the domain (as for example to expose simple json files), so it didn't follow the neat pattern I was expecting.
For the both of them, the solution was, as you may guess, time. Having someone with experience with hexagonal architecture to look at what I was doing was a great help, but I still made a lot of mistakes. However, I think that given that everything goes through interfaces, even mistakes are contained to one part of the app.
Thanks for the brief explanation :)