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?
Yes absolutely. As I mentioned in the talk, it was to show that you can provide some kind of intelligent stubbed service for your consumers. If you don't need that kind of "beta test", you can simply keep the stub in the tests. You can also create an Stubbed implementation of the SPI in the infrastructure.
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 ?
Hİ Julien, great talk it motivated me to do hexagonal architecture with Jakarta EE and there is one thing i can't get my head around it, the trick at 29:00 you talk about. how to do that with JPA and CDI, thank you again for the talk. I mean how to use model classes as @Entity without cluttering the model.
I think it would be completely different classes with JPA annotations. Same as SwapiResponse is mapped to StarShip in the presentation, some kind of StarShipEntity (sitting in JPA layer) will be mapped to StarShip as well. But I can be wrong.
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.
I do not agree with most of your post, but the point "the db access is just an infrestructure" is very valid. You cannot expect db access to be outside of domain in any data intensive application. Your business logic will be embedded in sql statements as it is most performant way to retrieve/modify big data.
Great presentation.
Without a a doubt on of the best talks I’ve seen on architecture. Explaining both the why and how.
One of the best explanations ever on the Hexagoanl Architecture. Thanks a lot
very nice
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?
Yes absolutely. As I mentioned in the talk, it was to show that you can provide some kind of intelligent stubbed service for your consumers. If you don't need that kind of "beta test", you can simply keep the stub in the tests. You can also create an Stubbed implementation of the SPI in the infrastructure.
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.
You have explained well the h.architecture
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 ?
Hİ Julien, great talk it motivated me to do hexagonal architecture with Jakarta EE and there is one thing i can't get my head around it, the trick at 29:00 you talk about. how to do that with JPA and CDI, thank you again for the talk.
I mean how to use model classes as @Entity without cluttering the model.
I think it would be completely different classes with JPA annotations. Same as SwapiResponse is mapped to StarShip in the presentation, some kind of StarShipEntity (sitting in JPA layer) will be mapped to StarShip as well.
But I can be wrong.
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.
I do not agree with most of your post, but the point "the db access is just an infrestructure" is very valid.
You cannot expect db access to be outside of domain in any data intensive application. Your business logic will be embedded in sql statements as it is most performant way to retrieve/modify big data.
by Julien Topcu