For small-scale applications, it is possible to manage with just a single module. By following common examples and utilizing a global variable, there is no need to constantly search for modules by name. Adding one extra global variable is not a significant issue, especially if it has a recognizable name like the "app" module for anyone reviewing your code.
However, maintaining only one module for a medium to large-sized application goes against best practices. It is not only inefficient but also illogical to create a module for every individual component (such as a controller). While it may seem excessive, organizing modules based on artifact type ('myControllers', 'myDirectives', etc.) could be more beneficial than having none at all.
The key is to identify and establish modules in a logical manner:
- Which components should be grouped together?
- Are there any dependencies between artifacts and modules?
- Does the dependency structure resemble a tangled mess or a structured tree?
- Are there standalone units that could exist in a separate web application?
- Could any artifacts be shared as an open-source module?
- Can the application be divided into vertical (login, user-admin, statistics) or horizontal parts (access-layer/caching, logic/communication, UI)?
In a medium-sized application, it is typical to have around 10-30 modules. Some of these modules (~10) may be reusable in other projects, while others are specific to the domain. The ideal number of modules varies depending on the app's size and desired granularity. Having fewer than 30 modules allows for easier management without getting lost in complexity.
Regarding other concerns: In Angular 1.3, the number of modules does not impact the application once it is loaded. There is a single injector where all artifacts are injected using their unique names (except for directives, which can share names). Angular avoids cluttering the global scope with new variables by referencing artifacts from the injector "registry."