You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

This document describes the architecture of Apache Fineract CN, an Application Framework for Digital Financial Services (Framework), a system to support nationwide financial transactions and to support the creation of an inclusive, interconnected digital economy for every nation in the world.

Design Principals

Domain Driven Design

Based on Evans’ Domain Driven Design, we’ve taken a close look at the solutions we have built, decomposed the functionality, and rearranged them based on bounded contexts we have identified. In addition we have taken recent research by the World Bank into consideration identifying the core domains for digital financial services:

 

Domain

Resource

1 Organization Management

1.1 Users

1.2 Permissions

1.3 Roles

1.4 Offices

1.5 Employees

2 Customer Information System

2.1 Customers

2.2 Identities

2.3 User-defined fields

3 Group Management

3.1 Groups

3.2 Meetings

4 Loan Portfolio Tracking

4.1 Loans

4.2 Fees

4.3 Interest Calculations

4.4 Repayment Strategies

5 Deposit Account Management

5.1 Deposit Accounts

5.2 Fees

5.3 Interest Calculations

5.4 Line of Credit

5.5 Payment Strategies

6 Transaction Processing

6.1 Customer Transactions

6.2 Group Transactions

6.3 Teller Services

6.4 Standing Orders

6.5 Direct Debit Schemes

7 Accounting

7.1 General Ledger

7.2 Journal Entries

7.3 Trial Balance

7.4 Bank Reconciliation

8 Audit Support

8.1 State changes

8.2 Auth’n & Auth’z

9 Reporting

9.1 Customizable

Services

Based on these core domains we have created a set of services that allows any vendor to select, enhance, and extend the framework to build their own solution and provide continuous innovations on top of the framework.

In short, the service architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

CQRS

Every service is utilizing Command and Query Responsibility Segregation (CQRS) and Event Sourcing to enable fast processing and data enhancement with a clean separation of concerns. CQRS segregate operations that read data from operations that update data by using separate interfaces.

This pattern can maximize performance, scalability, and security; support evolution of the system over time through higher flexibility; and prevent update commands from causing merge conflicts at the domain level. To allow scalability and ephemeral behaviour every services is stateless, not storing any data or holding context related information, and supports multitenancy by default.

Containerization

The used patterns and specific implementation allows the containerization of any service provided by the framework. Because the bounded context provides a clean distinction between services, an available API supports seamless integration, and the stateless nature of every service, it is possible and preferable to run a service in an isolated unit.

We are reaching high availability, ephemeral behaviour, and scalability by utilizing containers and the ability to start and stop additional instances fast and without side effects to other services.

Dynamic Management

It is essential that containers are managed dynamically. A cloud native runtime will schedule containers, provide discovery services, allow the injection of configurations, and utilizes underlying infrastructure.

This orchestration is needed to automate the deployment of services to create a scalable and elastic runtime that can adjust to a growing number of consumers and transactions.

Components

The following diagram illustrates the used components:

Data Tier

RDBMS: A RDBMS is used to store relational data, providing a raw view. This data is optimized to be retrieved fast to create user based views, internal validation, reporting, or analytics. By default the framework comes with a MySQL integration, that can be replaced with any Java Database Connectivity (JDBC) compatible RDBMS.

NoSQL: Apache Cassandra is used to handle the fast processing of state changes and financial transactions. To lower the impact use case specific models will have on the RDBMS, and to foster clean data separation, NoSQL is used to create use case specific view models out of raw data.

Message Queue: A Message queue is used to provide signals to parties which are interested in the change of data to build use case related sets of data. Data then will be retrieved using the API of a service. Apache ActiveMQ is used by default, but can be replaced with any Java Messaging Service (JMS) compatible message queue.

Application Tier

Spring Framework: To create light-weight modules, and focus on business functionality the Spring Framework is utilized. Cloud native requirements like context and dependency injection, transparent data access, or easy deployment are reached through the Spring Framework.

Spring Cloud: In a cloud native environment features like discovery, distribution, and configuration are essential. Spring Cloud offers us a toolset that simplifies the usage of these features, and allows us to choose the best solution based on the underlying infrastructure services.

Core Components: On top of the Spring Framework we have build additional libraries to ease the usage and configuration of CQRS, security, and multitenancy. These libraries are easy to use and we are working on integrating them into the Spring Framework themselves.

  • No labels