Introduction
This page exists to give some background into why MIFOS-4305 needed to happen and gives some description about the structural state of the codebase that resulted from this story.
Background
Spike - Decouple Application Module explains why we wanted to take on this work and that the intention was to simply split apart the big ball of mud module called application into two seperate parts. As a result the intention was to have one extra module called appdomain that would contain everything needed to allow the service facades (application services) to be exposed/releasable within a JAR and have them work.
Result
Whilst splitting out the code from application into appdomain, I ran into a problem with a dependency between application and questionnaire module. Basically the QuestionnaireServiceFacade class was using two services, the interfaces of which were defined in the questionnaire module but their implementations existed in the application module. This was a bit of a problem to completing the work and at this point I wrongly decided that I needed to try to start by decoupling code for one of the services to begin with, the AuditLogService. This resulted in me pulling out code into the abstract-domain and organization modules. It was only the next morning that I realised I didn't need to do that work but that I should instead move the service facade and the two interfaces defined out of questionnaire module and into the appdomain module. I didn't back out the work around abstract-domain or organization as this work will need to be done at some point anyway.
Resultant Mifos code base structure
As a result of the work described above the module structure of mifos is currently broken down like follows (described in build order):
- common
- domain-dto
- testFramework
- serviceInterfaces
- userInterfaces
- accounting
- questionnaire
- cashflow
- abstract-domain
- organization
- appdomain
- application
common
- produces a JAR file