The purpose of this article is to explain the necessary steps to work with Modules.
The first step is to break down the problem into simpler sub-problems. Defining a Module object for each one of them, as explained in the article HowTo: Create a Module Object, can be useful the first time you use the Module object. The newly created Module objects may, in turn, be broken down into simpler sub-problems, and so on.
This will create a Module hierarchy or organization.
Tip: The best way to break down a problem is to search for groups of similar requirements and arrange them into Modules. For example, Modules may be used to solve a set of business operations with conceptual cohesion.
Following the definition of our Module organization, the process that defines each interface begins. In most cases, this may also be done further ahead. However, the sooner it’s done, the better. This process will define how Modules should interact in relation to one another.
It should be kept in mind that the main purpose of the interface is to protect other Modules from the effects of the significant modification of objects, and the internal design decisions made to the Module, as well as to provide the services required.
See Modules - Defining an interface.
To have things clearer, it is best to maintain the interaction between modules as minimum as possible. Use the Module Diagram for a clearer view of relationships between Modules, and then proceed to fine-tune the interaction.
Having defined the interaction, the interfaces, and the module structures, the development process may then begin.
HowTo: Merge two or more Knowledge Bases into one using Modules