Use nested layers of DFD
Generally the best way to tackle complexity in any software system is to simplify it. One of the better ways that I have found to simpify diagramming complex software is to break it up into layers with differing granularity of concept.
Diagram 1 has a very top down highest level overview of your system. This almost doesn't have any real logic behind it more that it outlines how your highest level systems hang together. If you wish to see how a particular system works you look at another diagram.
Diagram A goes into more detail about how System 1 works, however once again this is a high level overview and outlines how system 1 works conceptually, however actual logic is referred to futher sub diagrams.
At the lowest granularity this is where the actual logic for the system comes into play and so like object inheritence in code (assuming you're using OOP/OOD) you have multiple levels of abstraction in your DFD as you do in your code and so the actual implementation details are delegated to your finest granularity of objects.
However at each layer there should be rules regarding cognitive complexity. Like code your diagrams should be able to be understood easily within 5 minutes or less.
Well designed code should also follow the above rules for cognitive complexity
Generally this is how your code should be layed out as well, well designed code should also be easily understood within 5 minutes or less.