> Yeah, that's probably true, but I want to vent a little anyway
You got me!
> I will however point out that Spring and Hibernate, etc are NOT tightly-coupled. You absolutely do not have to use any particular database persistence library with Spring, or any particular message bus framework or anything else. If you want to use jOOQ or MyBatis or raw JDBC or anything else, go nuts. The fact that most people gravitate toward certain de facto defaults doesn't make those requirements whatsoever.
With tight coupling I actually meant tight integration and each bringing their own set of weirdness.
> Regardless, I'd be surprised if it truly obviates the need for unit tests.
Nah, absolutely not. But you get proper separation of concerns. You are almost doing it if you do spring. You just need a lot of interfaces and separate those concerns along specific lines. This gives you plain java domain code, isolated code for each type of side effects (be it web or files/database stuff) which you can test. You can also replace components very fast and easy without big refactorings.
My biggest pain with Spring/Hibernate/whatever is that it permeates every layer, even if you don't want it to. I brought up Hibernate because it took me ages, that Hibernate proxies everything and spring security doesn't understand that, doing funky things if you check proxied objects (don't get me started on string SpEL ... worst idea ever. Can't test shit and doesn't protect you from typos). And it just happened sometimes. That sometimes was when there was any lazy loading involved. Fun times!
With hexagonal (ports and adapters) you force yourself to separate the concerns. We also enforce it via gradle multi-modules and architecture tests. It works quite well so far. No damn compromises because hibernate forces you to have nullability in domain models where it wouldn't be possible from a domain point. It's all in different modules, hidden from everyone else. It also forces you to write domain code in plain java (or in our case kotlin). No funny side effects because of lazy loading, hibernate proxying, jackson funny business or anything else. It's been a bliss so far. We had to replace a lot of spring boot magic auto stuff (like anything hikari, hibernate, repos, models, DDLs, we need to do that manuall). But we can actually properly unit test code knowing that it can't fail a few layers up because of something missing. We can properly use Kotlin with all of its niftyness with sealed classes and so on. Really nice! Now we just need to solve the bean issues with additional tests and the typical gradle/java annoyances of throwing hurdles at you just because and then we have a very nice stack we love to use. And no footguns because we enforce a lot via compile time safety checks. We try to design everything so that it can't be used wrong. And best of all: a test suite without every test using something with transactions, a full application context or anything. Plain domain code, plain Kotlin tests. It's a big step up.
I can only recommend having a look into that. It's not that far away from a Spring Boot app with a lot of interfaces and Beans implementing that.