When should we create a module?

Topics: Prism v2 - Silverlight 2, Prism v2 - WPF 3.5
May 15, 2009 at 5:00 AM

Hello,

I have a few fights for seperating the modules in our group. :) When should we consider creating another module?

Based on my understanding, we should create another module if it has some business values.

For example:

1. Creating Module that run without depending on other and that module can be sold to customer without any other module.

E.g. We can create Sale Module, Purchase Module so that we can sell the individual module to customer.

2. Creating Module as a addon for existing module.

E.g. We can create Promotion Management Module as a addon for Sale Module. That module won't be able to run without Sale Module but we can sell that module as addon to customers who bought our Sale Module. So, it has buz value.

What do you think about those two facts?

Some people used to create the module based on User Story. I think this is wrong approach. What do you think?

Some people says that one module shouldn't have more than 20 Views. So, they make different modules even there is no business value.  I'm not sure whether they are right or not. I don't think it's good idea to have one BIG module with a lot of views as well. But not sure whether we should have Module A and Module B even we can't sell those modules individually.

May 18, 2009 at 7:49 PM

Hi Michael,

 

In my personal opinion, this questions does not have just ONE right answer. A module, as a technical concept, is a technology asset that will help you compose your application.

Modules will help you build a modular design, but how to map this technical asset (modules) to application requirements depends on your particular scenario.

 

Taken from the Prism-v2 documentation, Module Technical Concept :

A common usage of a module is to represent different portions of the system. The following are some examples of modules:

·         A module that contains a specific application feature such as news

·         A module that contains a specific subsystem, such as purchasing, invoicing, or general ledger

·         A module that contains infrastructure services, such as logging and authorization services or Web services

·         A module that contains services that invoke line-of-business (LOB) systems, such as Siebel CRM and SAP, in addition to other internal systems

It's a very common practice to have modules mapped to business structure (such as sales, purchasing, etc). But it's also common to have modules mapping a specific functionality (such as transferring money between accounts, paying bills).

 

Perhaps in your scenario, separating the modules by how you can “sell” them is the best approach. Other ISVs may have just one customer who will consume all the modules, and they choose to separate modules in order to increase the maintainability of the application (i.e. based on User Stories, or based on the distribution of the development team, or the frequency of updates of a particular feature, etc). On the other hand, you might also create a new module when you believe you can reuse a particular functionality across different applications.

 

You should keep in mind that (Prism-v2 documentation, Modularity Design Concept):

·         Modules are independent of one another but can communicate with each other in a loosely coupled fashion.

·         A module represents a set of related concerns.

 

So, as you said, tackling module separation by the amount of views it contains could not always be the best approach. Usually the views contained in the module will depend on its particular functionality.

 

Hope it helps!

 

Matias Bonaventura

http://blogs.southworks.net/matiasb