Functional Modules

(Under discussion, not final)

Mifos can be broken down into following functional modules. There are cross functional modules which are not covered here. Examples of entities abstracted by them are provided, along with their description. The modules are carved out based on loose relationships different concepts in the system.

• Reference Data: There is no behavior around this data in our system. In some cases it does determine the behavior of other entities. e.g. Account Type, Personnel Status. This data doesn't change very frequently, hence it can be cached for longer duration by other modules, if required.
• Organization: It models basic organizational setup of an MFI supported by Mifos. It includes entities like Center, Personnel, Office.
• Customer: It models customer information served by the MFI and their data. e.g. Customer, Client, Group.
• Product: It models the offerings of the MFI. e.g. LoanOffering, SavingsOffering. Accounts (below) depends on it.
• Accounts: This models the core of day to day business of the MFI on the active accounts with the customer. It includes entities like LoanAccount, LoanSchedule, Checklist.
• Payments: Mifos records the payment information on its accounts. Since there is a small link between accounts and payments, and behavior of core accounts is not affected by it, it makes sense to pull them out as a separate module. It includes entities like Account Payment, Account Transaction, Chart of Accounts, etc.
• Questionnaire: Question and answers related to surveys and interviews done in Mifos. This is already built as an independent module. This has no impact on the business logic in Mifos, hence it is easily decoupled from entities with which the question/answers are maintained.
• Cash flow: (This is/would-be a new module). Cash flow manages information related to cash flow of customer's accounts. This information, unlike questionnaire is has business  impact on accounts.

Dependency between modules

The above table indicates dependency between various modules. The successive rows depends on their predecessor directly or indirectly. e.g.

• Organization depends on Reference Data, i.e. it cannot exist without it. 
• Customer depends on Organization and Reference Data.

Questionnaire is a orthogonal module, acting more like tags/meta-data captured as questions/answers on entities in the various modules (pretty much all except, reference data may be).

Please note that this is just domain dependency and some of the code level dependency might differ. How these they translate and issues around implementation would be covered in architecture related documents. (this is work in progress).

Issues

Meeting currently is a shared concept used by various Customer, Product and Account modules. We need to resolve this.

Reference

Rough but complete domain model based on current codebase. git://mifos.git.sourceforge.net/mifos/documents/design/modules/MifoDomainModel.(xmind/mm)