Fineract is spread into roughly 30 projects. This is an overview of the various categories of projects, their generic structure, and what role each plays in the Fineract CN ecosystem.
| Table of Contents |
|---|
Libraries
Libraries are not deployable pieces of code. They are intended to support the common functionality of the services. Most library projects produce one build artifact and contain unit tests for its classes. I've listed a few specific libraries with the integration tests since they are only used there.
lang
Description:
api
Description:
async
Description:
crypto
Description:
mariadb
Description:
cassandra
Description:
command
Description:
test
Support for unit tests and component tests in the services
anubis
Description:
permitted-feign-client
Integration Tests
Integration tests run multiple services together to check that their interdependencies work as intended. Integration tests are named for the services they include.
demo-server
demo-server is a project which uses the same methodology as the integration tests to deploy all the services together except the UI and to provision them in a generic way. This is a reasonable place to start in playing with deployment. You will need to understand its provisioning code to be able to provision in your production environment.
It is unlikely that you will be able to build a production environment based solely on demo-server, because the microservices are designed for a cloud deployment in which services run in containers and scaling up is achieved by spinning up new instances. Demo-server simply runs all the services on your own machine.
Keep in mind that because of the number of processes involved and the resources required, startup of all the services is rather slow, and older computers may "choke" on the demo-server. In particular, I strongly recommend an SSD drive.
test-accounting-portfolio
Description:
test-provisioner-identity-organization
Description:
test-provisioner-identity-rhythm-portfolio-accounting
Description:
service-starter
A library which starts services, eureka, and ActiveMQ for use in the integration tests and in demo-server.
default-setup
A library which contains example setup information. Currently only contains a standard chart of accounts for the accounting service. Should in the future contain roles for identity, and other useful standard data for the rest of the services for a generic initial setup.
UI
fims-web-app
Depends on all the services above (except group) to provide back office functionality.Description:
Services
Services rely on libraries and sometimes each other. They are built as spring boot deployable jars. Some service projects include libraries intended to support other services in functionality closely related to their own. We started off giving the services the names of egyption gods. These names are still visible in the data structures for the services. So I've included their "code" names here.
...
This is the spring boot deployable. When running it registers with a Eureka server, connects with a mariadb and a cassandra database, and provides a REST interface, with endpoints grouped into permittable groups. When initialize is called for a tenant within the service, the service allocates tables and other resources specifically for that tenant.
api
This is a feign client to make it easier for java clients to communicate with the service. The api artifact contains constants defined for listening to ActiveMQ events emitted by the service. The api artifact also contains constants naming the permittable groups which define the permissions which the service offers.
...
Tests in component-test start this service and only this this service to test the functionality offered by it. Tests make their calls into the service via the feign api.
provisioner
Code name: seshatDescription:
Use the provisioner to create tenants and assign services to those tenants. The provisioner is responsible for allocating databases, tracking which tenant has access to which applications, and taking care of the "magic" which allows applications to provision their own resources and declare which permissions are available for the application.
identity
Code name: isisDescription:
Identity keeps track of the permissions available for the applications, allows administrative users to compose those permissions into roles, create users, and assign roles to users. Identity authenticates users with passwords, and provides bearer JWT tokens via which other services can check a request's authentication and authorization. Identity can also authentication services and check if a service has the "right" to act in a user's name.
rhythm
Code name: khepriDescription:
Provides services with the ability to request notification at a certain time. Useful for daily interest calculation and other offline jobs that should be done once and only once.
accounting
Code name: thothDescription:
Keeps track of accounts, ledgers, and journal entries.
office
Code name: Description:
Saves branches, and employees and their relationship to eachother. Employees should have a 1:1 relationship with users in the identity service.
customer
Code name: maatDescription:
Tracks customers, including their contact details and identification data.
group
Code name:
Description:
...
teller
Code name:
Description:
UI
We currently only have one UI project.
fims-web-app
Depends on all the services above (except group) to provide back office functionality.
Integration Tests
Integration tests run multiple services together to check that their interdependencies work as intended. Integration tests are named for the services they include.
service-starter
A library which starts services, eureka, and ActiveMQ for the integration tests.
default-setup
A library which contains example setup information. Currently only contains a standard chart of accounts for the accounting service. Should in the future contain roles for identity, and other useful standard data for the rest of the services for a generic initial setup.
test-accounting-portfolio
Description:
test-provisioner-identity-organization
Description:
test-provisioner-identity-rhythm-portfolio-accounting
Description:
demo-server
Libraries
Libraries are not deployable pieces of code. They are intended to support the common functionality of the services. Most library projects produce one build artifact and contain unit tests for its classes.
anubis
Services which consume tokens created by identity use anubis to check them. Anubis uses spring security to manage authentication information, and publishes the permissions defined by the programmer for the service. Anubis also contains library support for testing services which use anubis for their security.
permitted-feign-client
Services which make requests to other services can use permitted-feign-client to transparently specify which requests and to request impersonation rights to specific endpoints for a user.
test
Support for unit tests and component tests in the services
api
Each of the services has a Feign api. This project contains code intended to support the creation of a Feign api.
command
Services are all implemented using CQRS. Command provides library support for asynchronous processing and audit-able NoSQL persistence of POST, PUT, and DELETE requests. The non-central eventually consistent persistence approach is central to our disaster recovery strategy.
mariadb
Most (but not all) services use an SQL persistence for querying of data via GET requests. This library provides tenant-separation based on header contents.
cassandra
All services save commands to cassandra. Some save other data there as well. This library provides tenant-separation based on header contents.
async
Handles correct multi-threading for command handling.
crypto
Hashes passwords.
lang
Miscellaneous. If you can't figure out where to put it, put it here. But first consider creating a new library projectdemo-server is a project which uses the same methodology as the integration tests to deploy all the services together except the UI and to provision them in a generic way. This is a reasonable place to start in playing with deployment, and you will need to understand it's provisioning code well to be successful, but it is unlikely that you will be able to build a production environment based solely on demo-server.