My condolences to you, youngster.
Spring isn't that hard once you understand that it's formed around a core, which is the Inversion of Control bean factory. This factory is the one-stop shopping point for all Spring-Managed JavaBeans and it not only constructs the beans on demand, but also can wire them together like TinkerToys™, eliminating the need for you to have to manually hard-code links between beans. So the starting point for Spring - as well as quite a few other frameworks - is to understand IoC.
In addition to the fairly small Spring core, there are various functional domains which group related services together and attempt to provide as much commonality of operation as possible - which helps to lower the learning curve. For example, there's Spring Data, which provides services for all types of database programming from simple JDBC to JPA to NoSQL DBMS's such as MongoDB and even the really exotic stuff like Neo4J. Or Spring Batch, which eases the process of creating batch-mode applications. And the increasingly-popular Spring Boot. There's a domain (Project) for almost any common complex function you're likely to need.
As for myself, I've seen so many DDD (drag, drop, drool) visual designers come and go, I can't count them. An assistive design tool such as Eclipse is fine, but once they start thinking they can run your life, look out. One of the things that ultimately pushed me out of the Windows world was having to do late-night panic fixes where the project could only be built properly if you had an obsolete version of Visual Studio (with patches applied) running on an obsolete version of Windows (with fixpacks applied). In other words, a 1-line fix that required 3 hours of building an antiquated custom development environment first.
These days, all of my projects can be build on a non-GUI machine. I use the IDE for development, but if I cannot build the production module without an IDE, it's not acceptable.
I sympathise on Maven, though. I resisted it myself for a long time, because I don't like processes that happen by magic. There is a method to the madness, though. It's basically programming by declaration, and PBD is actually quicker and more reliable than explicit code. It's taking advantage of the idea that projects are more alike than they are different, and once you know what files go where, it's actually easier to hand off a project to a remote contractor on the other side of the planet, because if you do a "mvn clean", zip up the project directory, and pass it on, the person on the other end can completely build an identical copy of that same project without having to do any special adjustments to the recipient's computer. Before Maven, I routinely had to deal with projects that couldn't be safely passed on to another department in the same company.
I've worked in every environment from stand-alone to start-up to the largest shops in town, but more often than not I seem to be the sole person on a very complex project. So I can identify with you. I don't go chasing after every fad - in fact I never bought into Ruby on Rails at all. But I do try to keep up with things that can make me more productive.