What granularity for a module?

Topics: CAB & Smart Client Software Factory
Feb 15, 2006 at 9:17 AM
originally posted by: GiriT

We are having some interesting debate about what level of granularity a "module" should be at..

We had toyed with the idea of having a module per Use Case to keep things very easy to distribute amongst our team and maximise potential reuse. That proved to be too fine grain.. from there we have moved to basically being quite entity led, grouping together the use cases for adding, editing and viewing a particular core part of the app into one module. This retains potential for re-use and also remains quite distributable in terms of development effort.

Anyone have any thoughts they want to share on approaches to this?

Are there any known issues with having a bunch of DLLS (say 10-20 ) loaded through the profilecatalog? Is it going to work till a certain point and then break?

comments, suggestions welcome :-)
Feb 15, 2006 at 9:44 AM
originally posted by: BradWilsonMSFT

The metadata stored about modules is relatively small. I can't forsee that there would be much problem in having 10s or even 100s of modules (although, to be fair, I haven't tested it).

Some of the real-world customers who are using these types of techniques tend towards calling the shell project the "Shell", and each module an "Application". So, within the shell, they have the HR application, and the Sales application, and the Inventory application, etc. The logical grouping of a "module" is of course not limited to a single DLL; it may be the module DLL and a bunch of support DLLs that the module DLL relies upon (and takes reference to).

This isn't the only reasonable scenario, of course, but it seems to be the most common one our customers are telling us about.
Feb 15, 2006 at 10:01 PM
originally posted by: Marcus_Hammarberg

I like the idea with the Shell-Application grouping. If I understood You correctly this will create a module per actor or role?

Will the WorkItems, in that case, encapsulate a usecase? Is there a recommendation there?

PS.
I really like the Smart Client Building Block. And the BaseArchitecture Toolkit is even better.
Congratulations on some great work
DS
Feb 16, 2006 at 1:02 AM
originally posted by: GiriT

We are certainly moving towards each workitem encapsulating a use case. It is the orchestrator that strings together the various views that make up a process. It also becomes the means by which you then move state from one view to another, and thanks to the state persistence capability of the workitem you can even "pause" the use case in mid execution.. at least that is the plan ;-)