You abstracts functionalities (possibly grouping them on affinities) from your main script that become a bare bone sketch of your desired behaviour of the application.

So if your application is ZXappz and you need to log and also use a database connection to read data you'll probably need a ZXappz::Logger and a ZXappz::Database modules. maybe the main ZXappz.pm just loads these two modules. Is ZXappz::Logger that uses log4perl and ZXappz::Database will load DBI

This in the simplest case ie when you just group functionalities into modules for a logical separation. The application can be one or more scripts that use such functionalities (subroutines exported by your modules) to do the work.

In this perpective you gained in readability and maintenence. But there is a better gain: you can document and test your software in a just one place: the module file. Better: you can embrass the "test driven" develop method that will save your time in the long run. You imagine a functionality let's say you want to write to alocal file whe the database is offline. Ok, first you choose a meaningful name like db_fallback_write and you imediatly spot ZXappz::Database as the right place to put it. Then, before coding the subroutine, you wite the POD documentation in the module for the functionality. you describe it as you wont it. Then you write an initial test (a .t file in t/ dir of the ZXappz::Database distribution) for db_fallback_write let'say return the name of the file written on success and 0 on failure. only now you start to code the sub db_fallback_write in the ZXappz/Database.pm file. You are defining an interface for your software: the db_fallback_write functionality want some parameters and returns something. it does it's work as described in the POD.

db_fallback_write may needs to chose a filename based on the day of the week. This is something private to the sub implementation: the final user of db_fallback_write (you or your script) does not need to know how the filename is composed. So in the ZXappz/Database.pm you can have a choose_filename sub (or as frequently happen a name starting with underscore _choose_filename ). choose_filename can have it's own tests but not POD documentation because it is not part of the interface but only of the implementation.

i hope i gave you the idea. wiser monks can add and specify about the matter. In my homenode you can search for the string About new modules to see a bounch of links on the subject.

HtH

L*