Jul 18, 2011 at 9:22 AM
Edited Jul 18, 2011 at 9:22 AM
There is no generic rule, it is just best to split things into sensible, logical groups.
For instance, the Contrib.DateTimeField and Contrib.ImageField modules are implemented seperately - you shouldn't have to install one just to get the other. The blogs module on the other hand has the BlogPart as well as the RecentBlogPosts part and
widget. It makes sense to group these together because they are related. This module also defines the Blog content type - so you are getting three features in one module, but clearly you can't have a recent blog posts part without the blog content type and
you can't have the blog content type without the blog part, so one module to encapsulate it all is the best fit.
Anything that might be reusable in multiple modules should be in a seperate module (should you have to depend on the blogs module to get a date-time field? No, so it is in a seperate module).
Inter-module dependencies are fine as well though - blogs may depend on the tags module so that the author of blogs doesn't have to implement their own tagging system - and blogs may also depend on the Users module for certain functionality.
If you want to have a module that lets you turn parts of it on and off independently, you can use the [OrchardFeature] attribute on your classes (along with multiple feature entries in module.txt) to define which parts of the module map to which features.