Java Backend Developer

A Good Fit

My previous experience at AXA, developing new microservices and working on a big monolith, made my experience a good fit for 4Finance’s needs: they wanted to split their big monolithic back-office into microservices, to improve scalability, reduce coupling and make deployments more independent.

Finance software often involves highly complex business rules. Because much of the business logic was tightly coupled, the acceptance test suite was one of the team’s most valuable development tools (I describe this in more detail here, in the Projects & Milestones section of my web).

Understanding the Domain

I joined during the first steps of this architectural transition. Although the long-term goal was to split the monolith into microservices, most of my work focused on understanding the existing system, implementing features safely and strengthening the acceptance test suite.

The team had a well-established Scrum workflow. The team consisted of three senior backend developers, two QA engineers, a Product Owner and a Scrum Master. This was my first experience in a Scrum environment.

My first few months were dedicated to understanding the platform, the business domain and the existing architecture. The biggest lesson I took from this experience was the value of acceptance testing. Combined with the team’s deep knowledge of the domain, it allowed developers to work confidently on a large and tightly coupled codebase.

A Change of Direction

Sadly, several key developers left the project, and our team was no longer responsible for driving the migration towards a microservice architecture. Instead, our work shifted towards maintenance and business-as-usual development.

As I wanted to continue growing in distributed systems and microservice architecture, I decided to look for a role that aligned better with those goals.