Api structuur

Overzicht technische Architectuur Aeolus

Met ingang van 2020 zijn we begonnen met het ombouwen van de Aeolus Back architectuur van een Monolith architectuur naar een microservices architectuur.

Eén van de voordelen daarbij is dat we naast een on premises oplossing ook een cloud oplossing kunnen aanbieden. Daarnaast geeft het de mogelijkheid voor de gebruikers om data te ontsluiten zonder het gebruik van Aeolus Userinterfaces. Denk hierbij aan het automatisch uitvragen van data ten behoeve van Datawarehouses.

Voor elke module zal de architectuur grotendeels gelijk zijn. Afhankelijk van de gewenste functionaliteit zal gekozen worden voor een ‘simpele’ architectuur of een architectuur gebaseerd op CQRS-ES¹.

De gekozen architectuur is wereldwijd ondersteund en wordt gezien als ‘standaard’.

Cliënt applicaties

De software die de gebruiker ziet of die de Api aanstuurt.
In tegenstelling tot Aeolus Back, zullen de nieuwe gebruikersinterfaces minder intelligent zijn en alleen de data aan de gebruiker presenteren en geen logica meer bevatten. Langzaam aan zal Aeolus Back uitgekleed worden en alle data vanuit een Api verkrijgen.

Api gateway

De gateway zorgt ervoor dat de client maar één ingang naar de Aeolus modules hoeft te hebben. Hierdoor wordt de toegang vereenvoudigd.

OAuth2.HenE.nl

Alle Api’s ondersteunen OpenID² en OAuth2. De basis hiervoor wordt verzorgd door het framework van Duende Identityserver. Hierdoor is uitgebreide authenticatie mogelijk.

De api maakt gebruik van een claim-based autorisatie, waarbij in de claims de rechten van de gebruiker staan.

De authenticatie ondersteunt de volgende mogelijkheden:

• Gebruikerscode en wachtwoord
• Uitgebreid met MFA via een authenticator app
• Aanmelden bij een externe partij, bijv. Microsoft Azure AD

Multitenancy

Alle Aeolus modules kunnen meerdere tenants aan. Hierdoor dient altijd de gewenste tenantId meegegeven te worden. Uiteraard vindt er een controle plaats of de gebruiker wel tot deze tenant behoort.

De module (Cak 2.0)

Verschillende modules zullen verschijnen die als microservices gebouwd zijn. Aeolus Cak is daar geen uitzondering op.

De architectuur van een module bestaat uit een aantal lagen.

De domeinlaag

De domeinlaag is het hart van de module. Hierin zit alle informatie m.b.t. het domein, denk daarbij aan aggregateroots, entiteiten, de verhoudingen onderling en
de regels met betrekking tot de data.

Een aggregateroot is het begin van het domein. In de Cak module is dat een CAK klant welke uniek wordt geïdentificeerd door het BSN en de gemeentcode.

Het exacte domeinmodel is intern en zal niet naar buiten worden gedocumenteerd. De documentatie van de Api en het gebruikte datamodel zal beschreven worden in de Api volgens de OpenApi 3.0 specificaties.

De Api

De Api is de toegang tot de module en is volgens het REST principe opgezet en via HTTPS communicatie te bereiken. Standaard zullen onze Api’s de ODATA v4.0 en de OpenApi 3.0 standaarden ondersteunen. OData³ maakt het mogelijk de data op een uniforme manier uit te lezen. De Api ondersteunt de volgende OData mogelijkheden:

• Select
• Filter
• OrderBy
• Count
• Skip
• MaxTop (bij de meeste Api’s zal deze op 200 staan, om een overbevraging te voorkomen).

OpenApi⁴ beschrijft de documentatie van een Api. Hierdoor is het mogelijk om de beschrijving van de Api en de modellen uit te lezen.

De datalaag

Ook de data moet opgeslagen worden. Dit is de verantwoordelijkheid van de datalaag. Onze nieuwe modules zullen standaard met MS SQL server werken. Indien gebruik wordt gemaakt van een scheiding tussen het lezen en het schrijven (CQRS) dan kan een aparte database gebruikt worden voor het lezen dan voor het schrijven. De datalaag is niet direct aanspreekbaar, alle communicatie zal via de Api gaan.

---