sd - 04 - microservice internals

issues with layered architecture

single presentation layer:

• hoe support je app / website / api

• gaan internal messages voorbij de presentation layer

enkele persitence layer

• hoe support je verschillende query patterns

• hoe caches opslaan

business logica hangt af van persistence layer

• hoe test je buisiness logica zonder db

what aje zo snel mogelijks status moe terug geven

x

hexagonal and onion style architecture

• waarom inward dependencies

Hexagonal / onion:

• doel: isoleren van externe afhankelijkheden

• de core staat centraal:

  • application layer: data + businessregels

  • domain model: use-case shit orchestration …

• rond de core:

  • inboud adapters: rest api, message consumers, gui shit → roepen business logica aan

  • outbound adapters: db, message broker, externe services → worden aangeroepen door de core

waarom inward dependencies:

inward dependencies = dat alle afhankelijkheden richting de application/domain core wijzen

waarom (zie slide 11, 21)

• business logica is onafhankelijk van de infrastructuur: core kent geen rest db kafka: enkel abstracties

• testbaarheid: business logica kan geetest worden zonder db of externe systemen

• business logica kan onafhankelijk van andere shit veranderen en andere shit kan onafhankelijk van business veranderen

• application layer geen dependencies heeft op adapters

• bv:

  • rest api imports application layer

  • rest api creates db adapter obj

  • rest api executes application layer function and passes db adapter

Transaction script vs (rich) domain model

transaction script

• 1 procedure per command / query

  • bevatten infrastucture isuues + business logica

  • workflow + validatie + berekeningen + db-calls in 1 methode

• alle business logica zit in application layer

• domain model bevat enkel classes met enkel state (aka data)

Rich domain model

• business logica zit in domain objects (entities / values)

• application layer = orchestration

• kleine gerichte klassen met duidelijke verantwoordelijkehdi

• oo design shit → makkelijk uitbreiden zonder veel code aan te passen

verschil:

• domain makkelijker te begrijpen ipv 1 grote klasse die lett alles doet

  • meerdere klassen: banking transaction / account → real world shit, mensen snappen

• oo patterns → uitbreidbaar

• domain model dwingt internal consistency af

 Patterns to create a rich domain model

• Entities, values, domain service and domain events

• Aggregates and repository

entity objects:

• domain concept dat gedef door identity ipv attributen

  • zelfde attr zijn geen 2 dezelfde objecten

• entity altijd in state consistent met business rules

• order, product

  

value objecten

Value objecten

• domeinconcepten zonder id, enkel gekend door attributen / values shit, meestal quantity

• enkel betekenis in context met ander object

• immuable en kan combineren met andere shit

• price / address

Domain services

Domain services

waarom

• domain model logica past niet in methodes / entity / value objecten of

• wanneer logica over meerdere entities of values gaat

wat:

• represent behavior → stateless

• orchestreren van business logica

• liggen nog steeds in domain model layer

aggregates

waarom:

• in rich domain model: elk concept is apart object → veel laden, niet altijd alles nodig

• niet alle relations zijn nodig om business use case te supporten

• moeilijk om consistency te behouden

• complex

→ Aggregates are groups of objects that act as a whole

bevat:

• root entitiy

• andere entities

• value objecten

regels:

• reference enkel de aggregate root

  • niet root kan referenties naar andere aggregate roots bevatten

• inter aggregate referenties moeten pk gebruiken

• 1 transactie maakt of update een aggragate

  • anders weer locking en dependencies maken

  • maak gebruik van saga wanneer meerdere transacties nodig zijn

repository classes

how to load en save aggregates, vormt de grens tussen domain model en data opslag

• geen: business logica / validatie / workflows

• enkel aggregate roots opvragen en persisten

domain events

= beschrijft iets dat gebeurd is in het businessdomain en waar de business om caret

• fact geen cmd

• generated wanneer een aggregate state veranderd

• triggers andere shit

  • state updates in andere / notification of a user

• maintain data consistency / notify nog shit kejet bla bla bla

  

Different methods for handling queries in a microservice architecture

CQRS

Naive way :

• queries lezen rechtstreeks uit domain model

• applicaties service laadt aggregates en mapt ze naar een view

• 1 model voor reads en writes

problemen:

• meerdere aggregates laden om view te populaten

• lezen uit domain model → vaak interne entities aanspreken → aggregate encapulatie breekt (expose internal state of domain objects)

• domain model wordt aangepast voor performance: extra fields / shortcuts / joins …

CQRS: Command-query responibility segregation = scheidt domain model in read model (queries, presentatie taken) en write model (afhandelen en verwerken van commands, business tasks)

• scheiding tussen commands en queries

• maternalized views → “caching van queries”

• queries gebruiken apart read model, los van het domain model

• separate write db from view db: read model kan eigen datastore hebben → optimiseer voor queries

hierdoor:

• domain model blijft clean / onaangepast

• betere performance

• eventual consistency

The api composition pattern

= patroon om 1 query te beantwoorden door provider services te bequerien

• privider service: owns deel van de data dat de query returned

Hoe werkt het (volgens de slides):

• Een API Composer ontvangt de query.

• De composer roept meerdere provider services aan.

• Elke provider service bezit zijn eigen data.

• De composer voegt de resultaten samen en retourneert één view.

Voordelen:

• Eenvoudig en intuïtief

Nadelen (belangrijk):

• overhead: meerdere request en db queries

• Lagere availability: composer kan gedeeltelijke / cached data returnen

• Geen transactionele consistentie (meerdere DB’s).

Wanneer niet geschikt?

• Als de query moet filteren op data die een service niet heeft
  → dan is CQRS met een read model beter.

waar zit de composer:

• Client: client composeert zelf de resultaten

• API Gateway: als de query deel is van de externe API

• Standalone service: als de query hergebruikt wordt of te complex is voor de gateway