Architecture

This page outlines the architectural structure and implementation for Elsie F release.

Layered Architecture

Mifos right from Mifos 1.0 there has been a layering problem. This resulted in the following:

UI Behaviour leaked into domain model
Domain logic/rules leaked into UI
Persistence leaked into domain model and UI
Configuration, Localization related code leaked into domain
No clear SPI or API existed and where services did exist, it was only possible for the web-based UI to consume them.
Code has become overly complex and hard to understand, maintain and add to as a result.

This intertwining of responsibilities was anchored in place by writing 'integrated tests' that were heavily coupled to the implementation.

The solution is to get clear seperation of concerns through the codebase. The start to acheive this we should at least get to a state whereby the codebase is in a layered architecture. While there are many ways to decompose a system we should strive to have at least the following layers:

Layer	Description
Interface (web based UI, other)	Responsible for accepting input from user and also showing information
Application	Typically a thin layer. Contains no business rules or knowledge. Describes the softwares capabilities and directs correct domain ojbects to do the work. Behaviour in this layer is meaningful to the business and/or used for intereaction with other systems.
Domain	Responsible for representing domain or business concepts. The technical details of storing the domain can also be considered domain but they should not be intertwined with the domain model.
Data	Data Layer, the medium that persists data, relational database etc

The layer of real interest here is the domain. This is the layer we truly want to isolate.

Elsie F Architectural Changes

Within the f-release, there is a set of application services used by the web-based UI across most of the application capabilities. Both the legacy UI implementation and the new UI implementation now both interact with this application service layer. We also restructured the codebase so that these services and their implementation and dependencies are delivered as JARs to the application WAR file. This means that going forward from f-release, it is now possible to consume these services either directly by calling Java API or by bolting on other consumeable services such as web-services etc.

See Spike - Decouple Application Module

See Decoupling Monolithic Application Module (MIFOS-4305)

See How To Use Mifos Application Services Delivered in JAR

Elsie F Architecture Diagram

For explanation of modules in diagram, see Decoupling Monolithic Application Module (MIFOS-4305)