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! 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.
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.
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.
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 ?
When it happened to me, i followed various approaches: A. If the cache is not part of the business-logic, I used the cache at repository level (on the SPIs implementation instead that putting it on the service) B. In the domain service, I've put another SPI, so, two interfaces, something like: starshipInventory starshipCachedInventory And wrote something like: result = starshipCachedInventory.find() .or(starshipInventory::find2) .orElseThrow(() -> new ElementNotFoundException()) C. I add a "Service" layer to the architecture. It basically imports the Domain Layer in the dependencies, but it does the CDI plumbing, and there I'm allowed to use Spring Boot annotations. The service class has the @Service annotation (And others, like @Transactional, @Cached, ecc...), it just Autowires the needed repositories, and calls the methods on the Domain Layer (I'm pretty sure "Tom Hombergs" has videos, and wrote a book about it) A is a simpler approach. B lets you implement/swap your cache, starting with a simple HashSet and then upgrading to Redis or something external C If you need a bit more complex hexagonal architecture
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
Without a a doubt on of the best talks I’ve seen on architecture. Explaining both the why and how.
Great presentation.
One of the best explanations ever on the Hexagoanl Architecture. Thanks a lot
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)
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! 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.
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.
You have explained well the h.architecture
very nice
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.
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 ?
When it happened to me, i followed various approaches:
A. If the cache is not part of the business-logic, I used the cache at repository level (on the SPIs implementation instead that putting it on the service)
B. In the domain service, I've put another SPI, so, two interfaces, something like:
starshipInventory
starshipCachedInventory
And wrote something like:
result = starshipCachedInventory.find()
.or(starshipInventory::find2)
.orElseThrow(() -> new ElementNotFoundException())
C. I add a "Service" layer to the architecture. It basically imports the Domain Layer in the dependencies, but it does the CDI plumbing, and there I'm allowed to use Spring Boot annotations.
The service class has the @Service annotation (And others, like @Transactional, @Cached, ecc...), it just Autowires the needed repositories, and calls the methods on the Domain Layer
(I'm pretty sure "Tom Hombergs" has videos, and wrote a book about it)
A is a simpler approach.
B lets you implement/swap your cache, starting with a simple HashSet and then upgrading to Redis or something external
C If you need a bit more complex hexagonal architecture
by Julien Topcu