...
- can be used as libraries by other modules.
...
Proposed Module Guidlines
Database/Schema management
- Should module be decoupled from each other to the extent that they can possibly have their own database? Implications: no foreign key relationship, possible independent hosting and deployment, lack of transaction, cannot do joins?
- No. Given Mifos is still seen as one application by its users, creating separate database would be an overkill. Also, there are no performance requirements which would forces us on this route currently.
- Should a module define and manage (provide a version and upgrades) to the portion of the schema that it uses?
- Yes. A module should include sql to create and initialize the portion of the schema that it requires.
Encapsulation
- What the extent of vertical slicing of modules? (i.e. does it include the presentation, action)
A functional module also consists of its own presentation code. The presentation code which delivers data from one or more module need to be handled in a separate mashup module or something like that. - Which layers in a module are accessible to another module at the compile time?
- The service layer would serve as the API for a given module. This could be explicitly enforced using OSGi bundles as well.
- Entities in one module would logically refer to entities in another module. Should these relationships be modeled at the entity level, as well? If not then how would the relationships be created?
- A module should not know about the entities in another module. This means that they cannot be linked together using hibernate relationship. But since there is relationship existing at database level, we should create reference objects and create mapping using it. Reference objects would have only the identifier (no behavior) and they would have immutable (hibernate term for read-only) mapping.
- Which module would host the page when data displayed is from two functional modules?
- Since the functional modules own the presentation of their data. Cross module presentation should be done in a presentation only module. This module depends on functional modules and not vice-versa.
- In case of One-to-One/One-to-Many/Many-to-One (logical) relationships between entities how to decide who refers to whom? How to avoid cyclic relationships between modules?
...