In Hexagonal Architecture, you can use whatever you want in your adapters, the infrastructural layer of your application. I’m using SpringBoot on all the application I’ve built using this pattern without the frustration of not having the capability of using everything I wanted to.

I’ll try to explicit some points here, but feel free to respond if I’m not covering your point.

In this architecture what we want to ensure, is the portability of the business logic, that’s why we want to avoid any technical dependencies in the domain.

But sometimes you want to take advantage of some powerful features of technical frameworks, and this last point can be an important impediment. It can seem weird but this is one of the strength of the Hexagonal Architecture because it forces you to ask yourself: “Do I really need this?”.

Let’s take an example with the ComponentScan of SpringBoot. Since I cannot annotate my domain services with Spring annotations such as @Component or @Service, it seems really difficult to rely on it. In that case, like explained in this article for the persistence layer, an inversion of control does the trick, in a way the domain becomes a dependence of the ComponentScan. You can configure Spring to be able to inject your domain object out-of-the box, you can checkout this article for more information: https://beyondxscratch.com/2019/07/28/domaindrivendesign-hexagonalarchitecture-tips-tricks-binding-the-domain-to-the-spring-context-with-componentscan/

Spring Security is a really good point and especially on the authorization layer. It seems a bit obvious that, it has to be the responsibility of your domain, since this is all about business logic. But if you want to handle this in your domain, you’ll have to pass to each domain method exposed to the infrastructure, at least the user. And in each exposed domain method, you may start first to do checks like “Does the user have this role?”, when Spring give you a pretty convenient way to do this using AOP and annotation with a lot of built-in bindings.

So yes, in that case a lot of people, including myself, still uses the Spring integration on the controller, when ideally it should be in the API implementation of the domain. What I usually do, when security checks requires a complex logic, I’m coding it inside the domain and exposes it to Spring. I’m still trying to find a better pattern which will be more domain based.

Sometimes you don’t have any alternatives, like I said I usually allow commons-lang3 in the domain because I don’t want to make the wheel again. In a way this is a risk assessment, one shouldn’t be dogmatic when applying hexagonal architecture, but should think about the trade-off of the adoption of a framework. So if you really want to use Lombok in the domain, you can make that choice. Just keep in mind what can be the impact on the portability of your business logic, and make sure to be really reactive if a framework is starting to add to much complexity in your business layer.

I usually avoid Spring in the domain because I think the risk is too important, the framework is too huge but I agree that is can be an obstacle for the adoption of the reactive pattern, because the language doesn’t support it natively — but may be some people have found a way to reconcile this with Hexagonal Architecture.

Hope this helps