Modular Programming

Question

Something quite common in the development of systems for business and how to satisfy several requirements, being these requirements often not used by certain customers, such as when a sales company would not need the service provision module that is used by service providers. Thus emerging the need for modular software development to meet such requirements

• The application is marketed by modules - the customer can buy the sales module, but not the industrial control.
• The application can be developed by separate teams - each team develops an independent module.
• Modules are only loaded when the user has access to it.
• The application does not need to be fully distributed when a module is changed
• We can create new modules and add them to the system without having to change the other modules

With a little reading on the subject, we can soon get to the Managed Extensibility Framework (MEF)

The Managed Extensibility Framework or MEF is a library for creating lightweight and extensible applications. It allows application developers to discover and use extensions without any configuration required. This also allows extension developers to easily encapsulate the code and avoid fragile rigid dependencies. MEF not only allows extensions to be reused in applications, but also between applications.

My doubt is around whether to use MEF?

There are other alternatives?

NOTE: Examples are always welcome.

Answer 1

Pablo, I’ve been working with this for a long time already using C# in an interdependent system! I think that even though it’s interdependent, we can generally modularize the system.

We have our own methodology to create our specializations by modules, not exactly as shown in Microsoft on the subject.

Our system started all modular, but over time it went (naturally) to be fully integrated. We have many customers who still buy only a few modules. But then an intrinsic need arises: integrations!

Example: Buying modules where you are an expert

Here’s a case: You’re an expert in inventory control and logistics. Your system is amazing in these modules, but it’s terrible at making amazing HML5 presentations with millions of updated photographs every week.

If a customer looks for you to be an expert on this subject, you will probably need several integrations: Incoming tax notes to know what is going into the stock (purchases and return of stock), an updated material register, an integration for orders and stock reserves and yet another for exit fiscal notes to give low stock. Perhaps yet another integration for notification of broken materials.

Modular sales

Nowadays we are already more mature with regard to the sales of modules in separate. Although we have modules and specializations (example, we sell the billing module. But in Brazil we invoice one way, in Chile another, etc), we also have a solid integration mechanism for all modules.

Naturally, there is an interdependence between all the modules. Even if the customer wants to buy only one module or another, it is necessary to map the interdependencies and make sure that he buys a solid product.

Specialized modular mechanism

The way we do it today is as follows: Our modules are loaded one by one by common interfaces distributed in the system. There is a Factory of those interfaces that checks, each time it is called, whether the module has already been loaded or not, if it is not it loads (each of our module is in a specific DLL by module and by specialization, for easy viewing).

We use the Reflection for such cases. It is worth giving a studied. We have a DLL common defining what is an object of the type Modulo and common interfaces that this object should implement. Then these objects can be instantiated and used when necessary.

You can call at any point of the system, for example, the billing module to invoice an order, example ModuloFaturamento.FaturarPedido(codigoPedido);. If the customer owns the module, the order is actually billed. Otherwise, a stub can be implemented to do nothing or an integration can be done with a request to an external system (example: SAP).

Summary

I believe that modularization is very feasible, but there is considerable spending on integrations when the customer does not want all modules. Try to specialize in the modules that your current customers give the most importance to. Understand everything about it and become a reference. The others will start coming more naturally if necessary.