This page includes proposed architecture ideas for the Cheetah release.

It should be noted that many discussions about these issues have come before both on and off the Mifos dev list and from various contributors. Some of these ideas have been captured on the following pages:

• MifosAPI
• ArchitecturePlans

Modularity

In this release we aim to divide Mifos into modules that can be developed, refactored or rewritten as independently of one another as possible.

Application Modules

• Customer
  • Client
  • Group
  • Center
• User
  • User
  • Office
• Financial Products
• Customer Account (Cash Account)
• Loan Account
• Savings Account
• Surveys/PPI
• Reporting
• Accounting
• Presentation/UI
  • It is worth some discussion about how the UI should be related to the individual modules it makes use of. An initial proposal would just be to consider the entire UI to be an independent module that can be replaced. Eventually to achieve a pluggable UI we might consider JSR-168 Portlets.

Infrastructure Modules

• Security
• Configuration
• Change Logs (Audit Logs)
• Database Upgrade Engine (Schema Evolution)
• Internationalization
• Logging
• Batch Processing

Application Module Internal Structure

Within an application module, a standard layered architecture will be followed including the following layers:

• Service Layer (application level operations)
• Domain Layer (business objects encapsulating business logic)
• Repository/DAO Layer (encapsulating CRUD persistence operations)
  • A repository layer is a buffer layer that decouples the domain layer from the database storage layer. Decoupling permits one to replace a database layer via Hibernate with another, perhaps in-memory store, that can speed up unit testing.

The Presentation Layer (UI) will only make calls to the application service layer. No business logic or transaction related code will be in this layer.

An Infrastructure Layer will provide services which are encapsulated in Infrastructure Modules.