Most people look at frameworks as a way of doing more with less. It's easy to look at frameworks as a bootstrap mechanism that abstracts the way most common work is done in software projects.
The problem with this view is that frameworks enable you to express your own domain ideas in a more streamlined manner. They aren't black boxes exclusively but, are, instead, ways of codifying your domain in almost a mini-DSL kind of way:
Persistency layer is abstracted way behind common patterns like the Repository pattern;
Services can encapsulate business logic;
You can manage domain concepts as first-class citizens "embedded" in the framework;
More than just abstraction - a mind map
Think of the last time you needed to encode concepts of your domain into the code. What did you do? How did you leverage your framework to help you do that?
Most likely, you embedded concepts of your domain into the code and combined them together using the building blocks the framework provided you.
Use the abstractions built for you at the right level
Once you start combining the framework API with your own domain concepts, you will end up creating a mini-DSL "implemented as the language" you're writing code in, but, you will be able to see all the concepts of your domain right as first-class citizens in your language while leveraging the framework to its full potential:
repository of Orders;
lists of Discounts, Products, Customers;
methods to retrievePremiumUsers, etc.
Build your own mini-DSL
When you manage to integrate concepts of your domain into the language you are writing code in, and, simultaneously, use the framework abstractions to combine both ends of the abstractions at play, you will create your own mini-DSL where you can effectively express business logic and requirements in code, in a way that people who will read the code, will immediately be able to map what they read to your business. That's the power of frameworks!