You have correctly realized that modularization is key for a well maintained software. Without a specific problem I will have to limit it to a general answer.
Each module has one function. That being said there are a few classes that represent the external interface for the module and others that are only used internally. Those that serve as an interface need to get everything they require for an action via parameter. If the parameters are non-trivial types, you should use an interface for the parameter type. That way the class only knows about a certain public interface of the objects it receives but nothing about the specific class.
Some modules need other modules. There is a simple approach to this. You have tools, services, materials and values (see tools and materials approach). Tools can use every type of class. A service can only use other services, materials and values. A material can only use materials and values and finally a value can only use values.
The values represent immutable values in the subject matter. In the banking area this might be an amount of money. Though the amount itself might be variable (you can have 100, 200, x bucks), the value is not. You don't change 100 to 200. You simply take the value representation of 200.
The materials represent things in the subject matter (like a bank account).
Services are used to change materials and operate subject matter operations (e.g. a lending service that is used to lend out movies). They also contain the business logic to determine if a certain operation is valid.
The tools are the interaction point with the user. They mostly work on one material or service. There can be sub-tools. The tools are the interface to the GUI (be it desktop based of web based).
That being said you can ensure that each module contains only one kind of classes and one responsibility.
But how does Dependency Injection now work without polluting other classes? It is allowed to use new statements within tools classes to create sub-tools. As tools are mostly technology oriented, it is not very easy to test it automatically (as they require other classes to do the heavy work). Important is that every dependency to another module (be it services, materials or values) is given via parameter.
In the end you need one class that ties the modules together, initializes the services needed in the software and gives them to the appropriate classes via parameter injection (be it in constructor or setter method).
The tools by the way get their needed object references (if not via parameter) from the GUI, so there is not much relaying of references through the system.