Take a look at Robert Martin's (aka Uncle Bob) Clean Architecture. Here's a quick overview.
Using this approach, you'll be able to defer details like Spring or Hibernate to a later time and focus more on the business logic. Or even migrate from Spring to Java EE without touching your business and application logic. You'll also get a testable application that complies with the SOLID principles, without too much additional effort.
I've just created an application this way and I must say I'm very happy with it. I could easily port it to a desktop or mobile application, or swap out the storage module. Details depending on policy goes a long way. It also promotes thinking in an API kind of way and, when applied correctly, making your modules very reusable.
Martin goes as far as saying details like frameworks are annoying and not part of your architecture. I do think they belong to architecture, but just at a different level. Often times you do want to include frameworks at an early stage to be able to produce a thin slice of a working application to demo to your users. Or when you know your frameworks in advance and there is no discussion about them, like in my case. But you could regard it as separate software architectures, when combined together create your application architecture.
