I think the underlying principles of DDD and Hexagonal Architecture are sound, but man, they make it so complicated. A good serving of KISS always helps.

- Keep your domain models separate from infra implementation stuff

- Architect your applications in sensible layers

- Decouple stuff that doesn't strictly belong together

This stuff should not need lists of XML config to get right, it's portable to any language or framework, and not just web applications.

Yes, incredible what years of Java Enterprise can inflict to the brain :-). It reminds me of the whole dependency injection circus where in the end it's just the equivalent of passing a function constructing an instance to another function in FP.

except the container can do whatever mumbo-jumbo you may want/need, like declarative transactions, declarative permission checks, logging, publishing events to external systems, etc.

and then you have async constructed dependencies, for example when you need to ask some server for configuration first, before service can be started, and with a good DIC the whole app will just wait automatically and you don't have to worry about any of that anywhere in your app (aka you are abstracted from this)

what you have said is not technically wrong but it also over-simplifies what DI is and it brings to the table

EDIT: that said, I agree in general, that java projects are over-engineered

Most of these things can be done with higher-order functions too.

I think that if Java had had lambdas earlier, Spring and other such frameworks might look very different. You can see that already, Spring is adding (experimental?) support for more declarative styles of configuration instead of the rather slow and hard-to-debug reflection magic: https://github.com/spring-projects-experimental/spring-fu