Lewis and Fowler provide a nice definition in their Microservices article. [1]
They drive modularity through the pattern of change, so their judgement is based on the development, rather than the code itself.
"You want to keep things that change at the same time in the same module. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged."
Although that article is about services, believe it can be applied to any type of modules.
They drive modularity through the pattern of change, so their judgement is based on the development, rather than the code itself.
"You want to keep things that change at the same time in the same module. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged."
Although that article is about services, believe it can be applied to any type of modules.
[1] http://martinfowler.com/articles/microservices.html