It would depend on the type of app but for me, it's mainly web apps. If one of my web apps get's huge, I take a hard look at the namespace (http://www.foo.com/webapp) and see if I can break it out into parts. For example, for a typical CRUD database app, I may do:

• http://www.foo.com/webapp/create
• http://www.foo.com/webapp/retrieve
• http://www.foo.com/webapp/update
• http://www.foo.com/webapp/delete

and then instead of all the logic (model,view,controller) being in one big-old-module (webapp), I would transition as much as I could to new modules which hold the logic for each piece of the app (with appropriate commonality in a webapp superclass). So the object hierarchy may look something like this in the file system:

• /path/to/foo/webapp
  • Controller.pm
  • Model.pm
  • View.pm
  • create
    • Controller.pm
    • Model.pm
    • View.pm
  • retrieve
    • Controller.pm
    • Model.pm
    • View.pm
  • update
    • Controller.pm
    • Model.pm
    • View.pm
  • delete
    • Controller.pm
    • Model.pm
    • View.pm

  As for when to do this -- I cannot say. For me it's more a comfort level decision. I tend to apply cohesion and coupling principles at the module level - when the module is doing too many things and I cannot reasonably reuse it, then I break it down.

  -derby

  Comment on Re^3: Avoiding loading modules