Probably you are not new and have the answer by now. The links from @KeesDijk and @Aaron should provide you a comprehensive answer already.
Since I also had the same question before, this answer could be useful for those who start learning Angularjs.
Should I have one module that contains all of the other objects in my application? This seems the easiest to set up, but this smells of the God Object Anti-Pattern to me.
You have the answer yourself. Unless it is a really small app, having a single module usually not ta good choice.
Should I divide modules up by types of objects? i.e. one module for controllers, one for directives, etc.?
Let's say you have 4 modules for controllers/directives/service/filter each, once you have more than 30 components. Each module have 7-8 components. As you have larger application, you will end up like the previous option.
Also, if you want to reuse one functionality, like user management, you will need to have dependency on several modules.
Should I divide them by use? So that all directives, services, and filters that are used for part of the application are together?
This is the most common recommended practices. One module/folder per one functionality. It is easier to reuse, read (by other programmers), and can scale as the application grows.
Reusability is also better, you can just have a dependency on module 'user'.
some other strategy I haven't yet seen / thought of?
Based on the previous option, you can have variants.
- It can be useful to structure your module in a nested way by sub-functionality. For example, you can have module 'user' which contains 'user-list' and 'user-edit' modules. (See https://github.com/angular-app/angular-app for example)
- You can have common/shared module separated out of the rest and prefix them. Ex. 'common', 'common-model-user', 'common-ui-modal', etc.
