Bezoekersactie
Je klikt op de knop.
Een kleine demo van hoe deze site verbonden is. Eén klik loopt door de UI, API-grens, persistentie, realtime broadcast en live state, zodat de stukken zichtbaar zijn in plaats van alleen beschreven.
Je klikt op de knop.
De component roept een getypte service aan en werkt de UI-state bij.
Een minimale endpoint ontvangt de actie en valideert de flow.
Het event wordt opgeslagen zodat de teller herstarts overleeft.
De backend pusht de nieuwe state naar elke verbonden browser.
Elke bezoeker ziet het systeem reageren zonder refresh.
Het runtime-pad toont waar een request naartoe gaat. Architectuur toont hoe de verantwoordelijkheden rond dat request georganiseerd zijn.
Dezelfde applicatieactie kan door heel verschillende structuren lopen, afhankelijk van hoe verantwoordelijkheden en afhankelijkheden georganiseerd zijn. Kies een architectuur en volg het request.
Dit zijn verschillende manieren om een applicatie te structureren, geen rangschikking.
Scenario: een gebruiker dient een request in om een gesprek te boeken.
Triggert de applicatieactie
bv. klikt op “Booking”
Ontvangt het HTTP-request
bv. ontvangt het Booking-request
Coördineert het businessgedrag
bv. valideert en verwerkt de Booking
Regelt de toegang tot persistentie
bv. creëert de Booking
Slaat de applicatiestate op
bv. creatie van de Booking-rij
Verantwoordelijkheden worden gegroepeerd in horizontale lagen, waarbij elke laag een specifieke technische zorg afhandelt.
De applicatie is eenvoudig en de afhankelijkheidsgraaf blijft overzichtelijk.
Naarmate de applicatie groeit, kunnen lagen strak gekoppeld raken en kan één bedrijfsflow over meerdere technische lagen verspreid raken.
Als je codebase duidelijkere grenzen nodig heeft, een nieuwe applicatieflow, of werk over frontend en backend heen, vertel me waar je aan werkt.