[Mifos-developer] Modularizing mifos: Questionnaire
Angshuman Sarkar
As part of ILM, we are working towards a new questionnaire module. For this, we want to build a completely independent module.
The idea being eventually we would want to move to plugin based architecture
- mifos-webapp : would be the host
- mifos-<module>: would be bundles, (e.g. web bundles/modules or slices)
- mifos-webapp would depend on interfaces defined in mifos-serviceInterfaces.jar
- individual module implementations would follow
* certain conventions for integrating with mifos web layer
* they would also implement the service interfaces, so that there is no dependency of implementations on mifos-webapp.
As steps towards that, we want to make "questionnaire" as independent as possible, closely mimicking packaging structure of a web-bundle.
To put simply: envisage that mifos web application has been broken into slices and each slice is like an independent web-app.
NOTE: we aren't there yet, but we want to be as close.
To do this for questionnaire module, this are some specific dependencies issues that I want to discuss here.
1) What do we do with utility or "framework" classes:
for example, should classes like ApplicationException, ServiceException, CollectionUtils be in mifos-webapp? I would recommend that we pull them out to the mifos-common module.
2) Should base classes like AbstractEntity be in mifos-webapp? Again I would suggest to pull them out to mifos-common module.
3) what about module specific domain entities that are currently under the mifos-webapp codebase? (this is a tricky one)
- questionnaire module uses the same entity "org.mifos.customers.surveys.business.Question.java" as the survey module, which resides in mifos-webapp.
Should we pull it to the new "questionnaire module" so that the older survey codebase works with dependent "mifos-questionnaire.jar" in mifos-webapp?
All the above are required to make "questionnaire" modular with dependencies resolved and not having bi-directional dependencies.
Looking forward to your comments
thanks and regards
~angshu
John Woodlock
>
> To do this for questionnaire module, this are some specific dependencies
> issues that I want to discuss here.
> 1) What do we do with utility or "framework" classes:
> for example, should classes like ApplicationException, ServiceException,
> CollectionUtils be in mifos-webapp? I would recommend that we pull them out
> to the mifos-common module.
That sounds sensible. +1 :)
> 2) Should base classes like AbstractEntity be in mifos-webapp? Again I would
> suggest to pull them out to mifos-common module.
Again sounds sensible to move common stuff into a common module (if
the abstract entity concept is still useful... it seems to be just
used to group 'entity' level objects)
> 3) what about module specific domain entities that are currently under the
> mifos-webapp codebase? (this is a tricky one)
> - questionnaire module uses the same entity
> "org.mifos.customers.surveys.business.Question.java" as the survey module,
> which resides in mifos-webapp.
> Should we pull it to the new "questionnaire module" so that the older survey
> codebase works with dependent "mifos-questionnaire.jar" in mifos-webapp?
>
I suppose it comes down to whether you are using
org.mifos.customers.surveys.business.Question.java because its
convenient to do so or because you have to i.e. is there some strong
connection between the older survey implementation and your new
questionaire implementation... maybe you are sharing question data.
If it is because it was convenient (probably not) then just create you
own class (es) and live independently. I must admit I thought the new
questionaire functionality would be a replacement for the older survey
stuff and there would be at most a migration at some point for older
customers.
if they are strongly connected I guess it would be important to
understand why that is before making a decision on what slicing makes
logical sense. I suppose the worst case is to pull all the survey
stuff into the new module.
John (not necessarily deeply thought out but liking slices)
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
Udai Gupta
> 1) What do we do with utility or "framework" classes:
> for example, should classes like ApplicationException, ServiceException,
> CollectionUtils be in mifos-webapp? I would recommend that we pull them out
> to the mifos-common module.
> 2) Should base classes like AbstractEntity be in mifos-webapp? Again I would
> suggest to pull them out to mifos-common module.
Thumbs up for the first 2 from me.
> 3) what about module specific domain entities that are currently under the
> mifos-webapp codebase? (this is a tricky one)
> - questionnaire module uses the same entity
> "org.mifos.customers.surveys.business.Question.java" as the survey module,
> which resides in mifos-webapp.
> Should we pull it to the new "questionnaire module" so that the older survey
> codebase works with dependent "mifos-questionnaire.jar" in mifos-webapp?
If two modules will share same entity, how are we going to prevent one
module from modify/create/delete the data for the other module?
How about using a discriminator (additional column in question table),
and have to different mappings using that discriminator.
SurveyQuestion and XYZQuestion (questionnaire)
Regards,
Udai
Keith Woodlock
Its great that this is happening and provoking discussion:
> 1) What do we do with utility or "framework" classes:
> for example, should classes like ApplicationException, ServiceException,
> CollectionUtils be in mifos-webapp? I would recommend that we pull them out
> to the mifos-common module.
Yes, there will be plenty of 'infrastructure' type code that will be
applicable to all modules so putting in something called common seems
fine. The problem with common modules is that over time they tend to
attract things that aren't really common at all but thats a different
discussion.
> 2) Should base classes like AbstractEntity be in mifos-webapp? Again I would
> suggest to pull them out to mifos-common module.
It sounds like something that is core-domain model but when you look
at it seems to be just a 'marker' interface as an abstract class. So
putting in 'common' is fine but its not really common, its just
applicable to marking/modelling entities.
> 3) what about module specific domain entities that are currently under the
> mifos-webapp codebase? (this is a tricky one)
> - questionnaire module uses the same entity
> "org.mifos.customers.surveys.business.Question.java" as the survey module,
> which resides in mifos-webapp.
> Should we pull it to the new "questionnaire module" so that the older survey
> codebase works with dependent "mifos-questionnaire.jar" in mifos-webapp?
>
> All the above are required to make "questionnaire" modular with dependencies
> resolved and not having bi-directional dependencies.
Its depends I suppose.
I think general with regards packaging/modularising I would follow
given set of principles
[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod]
REP The Release Reuse Equivalency Principle The granule of reuse is
the granule of release.
CCP The Common Closure Principle Classes that change
together are packaged together.
CRP The Common Reuse Principle Classes that are used
together are packaged together.
Seems to me that the 'question' sub domain is required to be used in
various places so it needs to be 'releaseable' to make it truly
reuseable. and Survey then is another praticular sub domain that
depends on 'question'. So survey probably only cares about 'reusing'
questions domain model and not all the other stuff (ui/etc) so we are
probably going to need modules that are pure domain (services, DAO and
entities/value objects).
Regards,
KeithW.
Shahzada Hatim
thank Bob Martin for that.
These names when used improperly become the giant bin for all kinds of
methods thrown in. It is an invitation to others that if you dont know
what it actually does you can throw it in the util/common folder.
Is it possible to avoid having a mifos-common package (and further
adding more stuff in it) and have even smaller packages whose name
tells exactly what they are about.
My 0.02 Kronas
--
Shahzada Hatim
Adam Feuer
<ang...@thoughtworks.com> wrote:
> As part of ILM, we are working towards a new questionnaire module. For this,
> we want to build a completely independent module.
+1 This sounds great!
> 1) What do we do with utility or "framework" classes:
> for example, should classes like ApplicationException, ServiceException,
> CollectionUtils be in mifos-webapp? I would recommend that we pull them out
> to the mifos-common module.
+1
That's what we made mifos-common for. The tests should go there also.
> 2) Should base classes like AbstractEntity be in mifos-webapp? Again I would
> suggest to pull them out to mifos-common module.
+1
> 3) what about module specific domain entities that are currently under the
> mifos-webapp codebase? (this is a tricky one)
> - questionnaire module uses the same entity
> "org.mifos.customers.surveys.business.Question.java" as the survey module,
> which resides in mifos-webapp.
> Should we pull it to the new "questionnaire module" so that the older survey
> codebase works with dependent "mifos-questionnaire.jar" in mifos-webapp?
+1
Yes, if there are classes that are only used by questionnaire module,
they should be moved from webapp to the new module. If they are used
by more than one module, put in common, or make a new module for them
(if there are a lot of similar classes).
Ideally we will end with no classes remaining in webapp, and all code
in separate modules.
Also ideally, I would eventually like to see a "main" module made,
with all code currently in webapp being placed there, so the webapp
module has no classes, jsps, or other code-related files (xmls,
properties, etc). Then it can simply contain various xml descriptors
to aid making the webapp, and it can include the main module jar and
the other jars.
> All the above are required to make "questionnaire" modular with dependencies
> resolved and not having bi-directional dependencies.
Cool!
cheers
adam
--
Adam Feuer <adamf at pobox dot com>
Van Mittal-Henkle
Hi Angshu,
Good discussion with you about this questions. I’ve noted inline some of the things from our discussion.
The idea being eventually we would want to move to plugin based architecture
- mifos-webapp : would be the host
- mifos-<module>: would be bundles, (e.g. web bundles/modules or slices)
- mifos-webapp would depend on interfaces defined in
mifos-serviceInterfaces.jar
- individual module implementations would follow
* certain conventions for integrating with mifos web layer
* they would also implement the service interfaces, so that there is no
dependency of implementations on mifos-webapp.
As steps towards that, we want to make "questionnaire" as independent
as possible, closely mimicking packaging structure of a web-bundle.
To put simply: envisage that mifos web application has been broken into slices
and each slice is like an independent web-app.
NOTE: we aren't there yet, but we want to be as close.
Nice summary, and yes you have captured where we want to go with overall structure. It’s worth mentioning that OSGi bundles are our most likely candidate right now for what will eventually be modules/bundles in mifos.
To do this for questionnaire module, this are some specific dependencies issues
that I want to discuss here.
1) What do we do with utility or "framework" classes:
for example, should classes like ApplicationException, ServiceException,
CollectionUtils be in mifos-webapp? I would recommend that we pull them out to
the mifos-common module.
2) Should base classes like AbstractEntity be in mifos-webapp? Again I would
suggest to pull them out to mifos-common module.
Mifos-common is intended for now to be the home of non-domain related functionality that is useful to share across modules. So utility classes would be a good candidate or generic exceptions. As soon as an exception includes domain concepts, then it seems that including it in the serviceInterfaces module would make more sense.
3) what about module specific domain entities that are currently under the
mifos-webapp codebase? (this is a tricky one)
- questionnaire module uses the same entity
"org.mifos.customers.surveys.business.Question.java" as the survey
module, which resides in mifos-webapp.
Should we pull it to the new "questionnaire module" so that the older
survey codebase works with dependent "mifos-questionnaire.jar" in
mifos-webapp?
Since we want to remove the whole legacy survey implementation upon completion of the Question Group module, creating an independent Question class in question groups would make sense so there is no lingering dependency. If there are any dependencies are the survey Question class, then those will need to be sorted out before it is removed.
--Van
Angshuman Sarkar
the new questionnaire module is checked in. Look for "questionnaire" module in latest head-master.
This module has no direct dependencies on mifos webapp. Mifos webapp has absolutely no direct linkage with questionnaire module.
However, there are few footpints of questionnaire module in configuration of mifos-webapp.
1) An entry in web-app-config.xml : to load the QuestionnaireContext.xml deployed with "mifos-questionnaire.jar"
2) An entry in cheetah-servlet.xml: for localized properties file. "org.mifos.platform.questionnaire.ui.localizedProperties.questionnaire_messages"
3) An entry in cheetah-servlet.xml: for freemarker config to discover templates under "classpath:org/mifos/platform/questionnaire/ui/views"
4) An entry in PersistenceContext.xml for questionnaire specific hibernate config file:
"classpath:org/mifos/platform/questionnaire/domain/questionnaire_hibernate.cfg.xml"
All the above are also solve-able programatically for having no footprints of mifos. However, I would expect all to go away, when we move to a proper OSGi Web Container.
The module requires bit more work and refactoring of course. But now that we have a near complete independent module, we can do it much quicker and incrementally (on need basis)
We can have elaborate explanations in next week's tech-huddle.
Have a great weekend.
thanks and regards
~angshu
Van Mittal-Henkle
the new questionnaire module is checked in. Look for "questionnaire"
module in latest head-master.
This module has no direct dependencies on mifos webapp. Mifos webapp has
absolutely no direct linkage with questionnaire module.
Bravo!!! This is a *big* step along the way to making Mifos the modular application that we want it to be. As you mention, there are small details to be worked out, but you’ve done the heavy lifting.
It’s great to see this and that you could take this step as quickly as you have.
Cheers,
--Van
Adam Feuer
<ang...@thoughtworks.com> wrote:
> the new questionnaire module is checked in. Look for "questionnaire" module
> in latest head-master.
> This module has no direct dependencies on mifos webapp. Mifos webapp has
> absolutely no direct linkage with questionnaire module.
Great work Angshu, Kalyan, Vinod, and Tejus (ThoughtWorks Mifos team)!
This proves again that we _can_ build a modular and flexible Mifos. Many thanks!
cheers
adam
--
Adam Feuer <adamf at pobox dot com>
------------------------------------------------------------------------------
Emily Tucker
Bravo indeed!
Great way to start the weekend!! J