Hexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable by

Nice Demo and one of the best Hexagonal implementations in java that I have seen. The domain are plain POJO's! (Well records so not so old :p)

Nice clean demo. Stub inside the prod code was something that I still can't get my head around. What would be other place to keep those stubs? In infrastructure?

Without a a doubt on of the best talks I’ve seen on architecture. Explaining both the why and how.

A word of caution: in microservices, these multilayer approaches are too expensive and brings no return of investments. If the service is reasonably small, it should be able ok to rewrite it or make a significant change to it. And refactoring is necessary to keep maintainable structure of a program in the face of non-trivial changes. Having many layers and conversion between layers with mostly duplicated data models makes it almost impossible to change code in any significant amount and on a limited budget. The performance is a problem too, DB access and other important practices (data oriented design in general) are not taken into account seriously (it's just a persistence layer, right). These patterns easily led engineers to create expensive but not really performant or scalable systems, which are hard to evolve, being brittle and fragile. The whole system then would be a distributed monolith, where each microservice would be a layered micro-lith on its own.

One of the best explanations ever on the Hexagoanl Architecture. Thanks a lot

by Julien Topcu

You have explained well the h.architecture

Great presentation! I had experience working with hexagonal architecture, but the domain used spring annotations to inject the beans, I had never thought of it that way.
I was in doubt about the infrastructure, the layer that calls swap api could be a module, no? Just like the controller layer could be another module, what do you think?
And I also don't understand the part of the controller where you're returning the same object used in the business layer, you could use mapstruct to do the ApiObjectResponse and BusinessObject conversions, so that when you added the new field, you hadn't broken your customers, because it's just a field that isn't being serialized in your controller.

What about the cases where you want to let's say cache returns from a service method. Spring Boot offers a @Cached annotation which can cache the return from the method. But since we won't be using spring in domain module no more, we won't have access to this capability and will have to roll our own cache. Do you have a strategy to handle this ?

very nice

Great presentation.