KakeiBro’s Domain

High Level Architecture

Without getting into the weeds of it just yet, we will make use of a UML Component Diagram in order to explain how the application is laid out:

architecture-component-diagram

Figure 1. High Level Breakdown of Architecture

React UI

When it comes to the UI side of things, a React with Vite application is the one powering the user interactions with the system.

Most important libraries:

  • Vite

  • Vitest

  • Emotion (compiled css styles in order to UT css behaviors)

  • Forms (React Hook Form)

  • Apache Graphs

.NET Modulith

Following the Modular Monolith architecture, the backend is a single ASP.NET Restful API that runs everything as a monolith, but has enough logical and physical modularization that is easier to maintain, extend but also faster to migrate to something like microservices.

Another way to look at it is a hybrid between a Monolith and Microservices.

Inside of it we have the following modules identified:

Users

Module focused entirely on the management of the users that can access the system. It will integrate with Google’s OAuth, and possibly with MFA.

Finances

Module focused entirely on the management of both the management of data and visualization of to the point indicators of personal finances.

Intelligence

Module focused entirely on more complex and insightful graphs, charts, tables that process all the finances data and give a much more round outlook on the health and areas of improvement for an individual’s finances.

Redis Database

Redis is a fully-fledged Database solution, focused on speed and with great extensions to its base service, whilst its behavior by default is an on-memory database. It also has integrations with files written into disk for persistency reasons, alongside OM (Object Mapping) capabilities that allow for an easy EF-Core like developer experience.

Disk File

This is the last part of the integration, whilst not a service itself, it’s a system file that will power Redis in order to keep data persistent (and allow for backing up extensions). By restoring state from a file the moment the service boots up, we can keep a consistent state of all the financial information.

Domain Driven Design

The system is focused on one specific idea: "Allow for someone to keep track of their finances by inputting their income and costs, processing that and showing much more insightful representations of data".

With this idea in mind, we need different modules/bounded contexts that help with the different functionalities that will allow for us to get the value out of the system, these modules are hard-coded into what will later be modules as both a concept and the backend’s logical units of separations.

  • Authentication

  • Users

  • Finances

  • Intelligence