THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Fineract is spread into roughly 30 projects, building each of which produces an artifact. This is an overview of the various categories of projects, their generic structure, and how they play a role in the Fineract CN ecosystem.
Libraries
Libraries are not deployable pieces of code. They are intended to support the common functionality of the Microservices. Most library projects produce one build artifact and contain unit tests for its classes. I've listed a few specific libraries are listed with the integration tests since they are only used in them.
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
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.
template
Though it is deployable, this service is not meant for deployment, but rather as an example of best practices in creating a service. When we create a new service we copy this project and then follow its instructions to specialize it. The template, like most services produces the following three build artifacts: Sometimes new best practices discovered while working on other services may take a while to migrate back to template.
service
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.
component-test
Tests in component-test start this service and only this service to test the functionality offered by it. Tests make their calls into the service via the feign api.
provisioner
Code name: seshat
Description:
identity
Code name: isis
Description:
rhythm
Code name: khepri
Description:
accounting
Code name: thoth
Description:
office
Code name:
Description:
customer
Code name: maat
Description:
group
Code name:
Description:
deposit-account-management
Code name:
Description:
portfolio
Code name: bastet
Description:
teller
Code name:
Description:
UI
This is one project which depends on the services.
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
Description:
default-setup
Description:
test-accounting-portfolio
Description:
test-provisioner-identity-organization
Description:
test-provisioner-identity-rhythm-portfolio-accounting
Description:
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, 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.