| = Principles |
| |
| == RESTful API |
| |
| The platform exposes all its functionality via a *practically-RESTful API*, that communicates using JSON. |
| |
| We use the term *practically-RESTful* in order to make it clear we are not trying to be fully REST compliant but still maintain important RESTful attributes like: |
| |
| * Stateless: platform maintains no conversational or session-based state. The result of this is ability to scale horizontally with ease. |
| * Resource-oriented: API is focussed around set of resources using HTTP vocabulary and conventions e.g GET, PUT, POST, DELETE, HTTP status codes. This results in a simple and consistent API for clients. |
| |
| See online API Documentation for more detail. |
| |
| == Multi-tenanted |
| |
| The Fineract platform has been developed with support for multi-tenancy at the core of its design. This means that it is just as easy to use the platform for Software-as-a-Service (SaaS) type offerings as it is for local installations. |
| |
| The platform uses an approach that isolates an FIs data per database/schema (See Separate Databases and Shared Database, Separate Schemas). |
| |
| == Extensible |
| |
| Whilst each tenant will have a set of core tables, the platform tables can be extended in different ways for each tenant through the use of Data tables functionality. |
| |
| == Command Query Separation |
| |
| We separate *commands* (that change data) from *queries* (that read data). |
| |
| Why? There are numerous reasons for choosing this approach which at present is not an attempt at full blown CQRS. The main advantages at present are: |
| |
| * State changing commands are persisted providing an audit of all state changes. |
| * Used to support a general approach to *maker-checker*. |
| * State changing commands use the Object-Oriented paradigm (and hence ORM) whilst querys can stay in the data paradigm. |
| |
| == Maker-Checker |
| |
| Also known as *four-eyes principal*. Enables apps to support a maker-checker style workflow process. Commands that pass validation will be persisted. Maker-checker can be enabled/disabled at fine-grained level for any state changing API. |
| Fine grained access control |
| |
| A fine grained permission is associated with each API. Administrators have fine grained control over what roles or users have access to. |
| |
| == Package Structure |
| |
| The intention is for platform code to be packaged in a vertical slice way (as opposed to layers). |
| Source code starts from https://github.com/apache/fineract/tree/develop/fineract-provider/src/main/java/org/apache/fineract |
| |
| * accounting |
| * useradministration |
| * infrastructure |
| * portfolio |
| ** charge |
| ** client |
| ** fund |
| ** loanaccount |
| * accounting |
| |
| Within each vertical slice is some common packaging structure: |
| |
| * api - XXXApiResource.java - REST api implementation files |
| * handler - XXXCommandHandler.java - specific handlers invoked |
| * service - contains read + write services for functional area |
| * domain - OO concepts for the functional area |
| * data - Data concepts for the area |
| * serialization - ability to convert from/to API JSON for functional area |
