A software GranuleOfRelease (or unit of modularity) is a collection of software with the following attributes:
- Performs, or contributes to, a specific functionality
- All software within the GranuleOfRelease is necessary for completion of that functionality; it would be difficult to use only part of the GranuleOfRelease. (It may be possible for specific such granules; but you shouldn't depend on that).
- May depend on other GranuleOfModularity (bad plural, I know); however the dependency graph among UnitsOfModularity should not contain any cycles. Cycles among classes (etc) within a GranuleOfRelease are generally OK, though they should be short (no more than 2 or 3 participating entities); anything larger indicates that ReFactoring may be necessary.
- The GranuleOfRelease is the granule of reuse - see ReuseReleaseEquivalencePrinciple.
Names given to granules of release in various languages and various works in TheLiterature include: class, module, package, cabinet, library, component, etc. Unfortunately, this is one area where the terminology could use some harmonization.
The phrase granule of release is chosen to avoid collisions with any of the above.
Many practitioners of various languages/paradigms insist that a particular language feature (such as the "class" or "module") is the proper granule of release. Languages which force the GranuleOfRelease to be a particular size usually result in maintenance/configuration headaches. That said, the UnitOfModularity generally shouldn't be smaller than a single class or stand-alone function. (Some languages require the GranuleOfRelease to be a class or first-class object; but allow other classes which do not have this functionality; that's OK. What is objected to is the notion that all classes should be releasable components).
Not to be confused with the GranuleOfDeployment. The GranuleOfRelease should be smaller than the GranuleOfDeployment.