CoBen Finance Service - payment processing application

Constructiv

CoBen Finance Service - payment processing application

Client: Constructiv

Constructiv is an organization providing services in the construction sector. It is a life security fund set up within the Joint Construction Commission whose members include Belgian construction worker syndicates.

https://constructiv.be/ 

What we did

  • Business Analysis
  • Design
  • Implementation
  • Maintenance

Introduction

The core of Constructiv's business is calculation of benefits for approximately 200.000 workers in the Belgian construction sector; its internal enterprise system called CoBen has multiple microservices that calculate various benefits or debts for collection in  case of overpayments. Therefore, CoBen required an efficient and manageable way of business users handling their payment flows. 

Constructiv initially requested Tacta's team to develop an application to process incoming payments and automatically match them to premiums or debts that needed to be collected. However, given the success of the project the business users also wanted us to handle processing outgoing payment requests. The Finance Service, a system built entirely under our governance, ended up handling the full payment cycle for CoBen.

Challenge

At the time we were onboarding the project, Constructiv was creating a new system to handle its benefits. The idea was to keep each benefit a separate service with an independent lifecycle. This has many advantages; in the parlance of domain-driven design, the bounded context is within one solution. There is no way that other services' code changes impact the benefits. However, this introduced a new challenge - communication. Those independent services need to sometimes communicate with the other services in the ecosystem.

In the beginning, the idea was to use REST endpoints. This however proved itself not satisfactory, given that each service could be unavailable. NServiceBus was the messaging solution chosen and this mean that CoBen has all marks of a microservice architecture. Finance Service was the first service to implement the communication using NServiceBus. That means that the versioning and ways to handle decoupling and the messages exchanged had to be defined first.

Since we were required to handle sensitive and heavy financial data, event-sources system was the way to go. Applications related to handling of financial data may be challenging but we benefited from out team's previous expertise in financial applications and applications that handle payment executions. We managed to build the domain together with the users and created an application that can later support multiple microservice applications that need to handle either or both, incoming and outgoing payment flows.

Tech solution

The service we were required to build had to be part of the main CoBen application, so our technology stack for backend (.NET) and frontend (Angular7) was alread defined. As previously stated, we used the Event sourcing development pattern which is highly efficient with financial applications and enabled us to provide audit trailing to our users layer. Domain-driven design principles were also applied, which enabled us to make the business domain the centerpiece of our development.


Results

  • The application proved such a succes and easily extensible that instead of just processing incoming payments as initially requested, our business users wanted it to cover outgoing payment requests too. Our application became the main financial app witin the CoBen ecosystem.
  • The advantages of an event sourced system proved to be great. Many times, we could extend the system by introducing new types of events, quickly adding logic without impacting the older code. And the greatest advantage was that we had request from business where we could apply the old events and they would have the new functionality populated with the data already in the system.
  • In the end, we managed to build software fast and enable:

    • maintanability - potential issues are easy to find, fix and and prevent

    • reliability - no data loss and self-healing system that is resilient to errors

    • audit trailing - all relevant events were used later to build historic records that users can consult

    Facts and figures