"How big should I make my application modules?" is another question I answer frequently for people.
Before being called "ApplicationModules", during early Beta's of BC4J they were called "WorkUnits". By design, they are meant to provide a service encapsulation (via their custom methods exposed to the client) and a central place to access the collections of value objects that the client application requires relating to some developer-defined unit of work.
They are designed to be "as small as the Use Case requires", but easily composable so you can assemble larger data model out of reusable, smaller components. This is why one application module can aggegrate nested "instances" of other application modules that it wants to include lock-stock-and-barrell in it's data model.
If you have a set of web pages that implement a given end-user task, you can use the same application module for the entire set of those pages. A sophisticated use of application modules can dynamically load and unload nested application module instances at runtime inside a containing application module instance as needs require.
10:39:40 AM 
|
