Frameworks are a very big part of software today. Framworks often provide much of the architecture of a system because a framework comes with a large number of design decisions alreay made. E.g. a Grails project uses MVC and active record patterns, it runs on java infrastructure, and so on.
In this essay in design by Len Bass, three sources of initial design hypothesis for a future system are listed: Existing similar systems, frameworks, and patterns. The essay points out that existing similar systems probably provide most guidance for the new systems, frameworks a bit less guidance and patterns least guidance. This makes frameworks a more desirable source of initial design/architecture than patterns.
While I agree with this overall, I want to point out a particular caveat in this post: Frameworks should always provide a way out. E.g. a Grails project might start out being served well by active record, but at some point active record may turn out to be too constrained for a few parts of the system. It is crucial to be able to bypass the framework in those few parts while still using the framework in the rest of the system. To continue the example Grails opens the possibility to drop down to Hibernate if active record is too constrained, and Hibernate in turn opens the possibily to drop down to SQL if so needed. Not all frameworks open these ways out, which means that you have to work against and around the framework when the framework becomes too constraining. Doing so invariably results in something quite unmaintainable, because those workarounds are weird and hard to understand, and because new versions of the framework likely will invalidate the workarounds.
Lastly, in my experienc projects always run into a few of those cases where the chosen framework is too constaining. So my advice here is to remember to consider what the frameworks you conisder allows in thoses cases where you want a way out.