Solutions to organize Guice binding configurations

Question

It's apparently a bad idea to put all bindings in one module, so what do you think is the more elegant way?

I think Bob's idea could be good start for this discussion:

It's hard to come up with one-size-fits-all rules for this sort of thing, but one Module per package is certainly a good place to start. Putting a Module in each package means you can make your implementation classes package-private--your Module will be able to access them and create bindings to them, but your users will not be able to access them directly.

Answer 1

Different modules for different modules within you application. I generally have:

A Module for configuring the database (loading a settings file, configuration the database connection strings & binding a data source to a pooling data source.

A Module for configuration settings (loading a settings file & binding the values).

A Module for binding the database layer interfaces to implementation.

Generally several Modules for binding the view as this is normally a little more complex than the database layer.

Generally several Modules for the controllers.

A few Modules for particularly complex classes.