Architecture sample

In order to make the applications clear and highly compatible, different types of architecture are used. The architectures used are listed and briefly explained why they have been used or why they are ideal for the use case.

Layered architecture

The layered architecture refers less to the complete system and more to the structure of the individual applications. For example, entity/database declarations are separated from the logic. The solid principle is thus achieved directly. The logic layer may use the entities of the database but the entities do not even know that a logic layer exists. The service is passed via the interface and not its concrete implementation. In this way, services can be exchanged or re-implemented without having to make major changes to the existing code.

Chart

flowchart TD
    A[Enpoint Layer]
    B[Logic Layer]
    C[Database Layer]
    D[Schema Layer]

    A-->|Call methods of|B
    B-->|Uses entities of|C
    C-->|Implement entites of|D

It is important to note that layers can also be omitted if necessary. Nevertheless, this structure must be adhered to.

Implementation

The layers can be ideally divided into maven modules. This also simplifies testing and targeted unit tests can be written to test areas more directly and precisely.

Kernel architecture mixed with event-based

To make services highly compatible, it is possible to extend applications with plugins. The plugins are loaded and have access to the logic level of the individual service. Events such as the creation/update/deletion of data records can also be recorded via the Spring event architecture. The kernel architecture is therefore used as the basis for loading and managing the plugins. The event base architecture plays more of a secondary role, as it is more or less a build-in for the application.

Chart

classDiagram
    class Kernel {
        - springContext        
        - springConfiguration
        - springEventManager
        + manager()
        + repositories()
        + configuration()
    }
    class Plugin {
        - pluginContext
        + EventHandler()
    }
    class OtherPlugin {
        - pluginContext
        + EventHandler()
    }

    Kernel --> Plugin 
    OtherPlugin <-- Kernel

Microservice architecture

First of all, it should be said that a pure microservice architecture has its own database connection and this synchronizes the connections. In our model, the synchronization of supabase is used, whereby the database is then seen as an egg layer. This architecture does not describe the complete structure of all services. It describes the extent to which the application is intended or designed. Due to the vertical scalability, the local storage of cache data is taboo and can result in a fatal loss of data if this is not adhered to.

Chart

flowchart TD
    subgraph services [Services]
    A@{ shape: procs, label: "service-core"}
    B@{ shape: procs, label: "service-payment"}
    C@{ shape: procs, label: "other service..."}
    end

    subgraph api [API Layer]
    graphql["GraphQL"]
    webhook["Webhooks"]
    end

    subgraph frontend [Frontend/UI]
    website["Website"]
    end

    database[(Supabase)]
    
    A --> database
    B --> database
    C --> database
    api<-->|Reqeust Data|services
    frontend<-->|Vizualize Data|api