There may not be a direct and detailed answer, because DDD itself is not a well defined thing. I just wanted to draw your attention to the fact, that not all interpretations of DDD end up loading/storing structures of data without context.
Even Eric Evans seems to shift his views, in essence telling us to concentrate on the "theoretical" parts of the book, like thinking in terms of "domain", language, behavior and expressing those in code.
The whole services-data structures thinking, as far as I can tell, is represented by the Vaughn Vernon wing of DDD. It is not the whole DDD community however.
Anyway, let's think about your problem a second. Why would you load a bunch of data before you even know what to do with them, or even if you know you will not need all of it? It doesn't really seem to make sense.
It gets worse however. Because you have one set of data structures (made up of aggregates, entities, value objects) without any business-context, you'll have to define a "validity" that is somehow common for all use-cases. This basically guarantees that this "model" will not be an optimal fit for any of the use-cases. You usually can't even optimize how it gets persisted, because at that time the data structures are again without any context.
The alternative is to concentrate on behavior. Load and store data from a database as needed while inside the context of a business behavior. Or execute pure SQL statements, third-party calls, etc. Do the optimal thing. This is the only way, you can implement a behavior optimally and don't have to wrestle with a generalized data structure with an all-or-nothing persistence strategy.
Is that DDD? Reading the blue book, I would say yes. Others may disagree. Again, I don't think you'll find an authoritative answer, you may have to think for yourself here and decide based on your requirements.