54 lines
2.3 KiB
Plaintext
54 lines
2.3 KiB
Plaintext
= Key Design 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**: The platform maintains no conversational or session-based state. This allows for horizontal scaling.
|
|
* **Resource-oriented**: The API is focused around a set of resources using HTTP vocabulary and conventions (GET, PUT, POST, DELETE, HTTP status codes). This results in a simple and consistent API for clients.
|
|
|
|
See the online API Documentation for more details.
|
|
|
|
== 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 FI's data per database/schema.
|
|
|
|
== Extensible
|
|
|
|
While 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.
|
|
|
|
== Package Structure
|
|
|
|
The intention is for platform code to be packaged in a "vertical slice" way (as opposed to technical layers like controller/service/dao).
|
|
|
|
Source code location: `fineract-provider/src/main/java/org/apache/fineract`
|
|
|
|
Major modules include:
|
|
* accounting
|
|
* useradministration
|
|
* infrastructure
|
|
* portfolio
|
|
** charge
|
|
** client
|
|
** fund
|
|
** loanaccount
|
|
|
|
Within each vertical slice, there is a common packaging structure:
|
|
* `api` - `XXXApiResource.java` (REST API implementation)
|
|
* `handler` - `XXXCommandHandler.java` (Specific handlers)
|
|
* `service` - Read + Write services for the functional area
|
|
* `domain` - Object-Oriented concepts (Entities)
|
|
* `data` - Data Transfer Objects (DTOs)
|
|
* `serialization` - JSON conversion logic
|
|
|
|
== Maker-Checker (Four-Eyes Principle)
|
|
|
|
Enables applications to support a maker-checker style workflow process. Commands that pass validation will be persisted. Maker-checker can be enabled/disabled at a fine-grained level for any state-changing API.
|
|
|
|
== Fine-Grained Access Control
|
|
|
|
A fine-grained permission is associated with each API. Administrators have granular control over what roles or users have access to specific functions. |