Software Architectuur
De Beperkingen van de Traditionele CRUD Applicatie
De overgrote meerderheid van webapplicaties is gebouwd rondom het vertrouwde CRUD-model: Create, Read, Update en Delete. De status van een entiteit (bijvoorbeeld de balans van een bankrekening) wordt opgeslagen in een databasetabel, en wijzigingen overschrijven de bestaande rij in de database. Hoewel dit voor eenvoudige informatie-systemen volstaat, verliest u bij een UPDATE actie de meest waardevolle informatie van uw bedrijf: de intentie en de historie. Als een klant in het systeem een adres wijzigt, is het oude adres voorgoed verdwenen. In kritieke systemen zoals de bankensector, boekhoudpakketten, en complexe supply chains is deze destructieve vorm van dataopslag (waarbij history verloren gaat) onacceptabel. De oplossing hiervoor ligt in twee geavanceerde architectuur-patronen: CQRS en Event Sourcing.
CQRS: Het Scheiden van Commando’s en Queries
De Command and Query Responsibility Segregation (CQRS) architectuur stelt dat de datastructuur en processen die worden gebruikt voor het lezen van data (Queries) fundamenteel gescheiden moeten zijn van de datastructuren en processen die data wijzigen (Commands). In een complexe e-commerce omgeving vereist het inzien van een productcatalogus (Query) razendsnelle zoekacties op basis van tientallen filters, en wordt deze actie duizenden keren per seconde uitgevoerd. Het plaatsen van een bestelling (Command) vereist echter zware bedrijfslogica, voorraadcontrole en transactionele veiligheid, maar gebeurt veel minder vaak.
Door het lees-model (Read Model) los te koppelen van het schrijf-model (Write Model), kunt u ze onafhankelijk van elkaar schalen en optimaliseren. De Command-zijde communiceert met een relationele database om veilig bedrijfsregels te valideren, terwijl de Query-zijde data wegschrijft naar een volledig ‘platte’, gedenormaliseerde weergave in Elasticsearch of een caching-laag (zoals Redis), klaar om direct naar het scherm van de klant te sturen.
Event Sourcing: De Intentie Vastleggen
Event Sourcing wordt vaak onlosmakelijk verbonden met CQRS. In plaats van de huidige ‘status’ op te slaan, slaat Event Sourcing alleen de gebeurtenissen (Events) op die hebben geleid tot de huidige status, in de vorm van een onveranderlijke (append-only) lijst (een Event Stream). Neem een bankrekening: in plaats van de tabel ‘Rekening’ op te slaan met de balans €150,-, slaat het systeem de volgende lijst events op:
RekeningGeopend (Startsaldo: 0)BedragGestort (Bedrag: 200)BedragAfgeschreven (Bedrag: 50)
Om de huidige balans (status) te bepalen, rehydrateert het systeem deze events in de software door ze simpelweg van begin tot eind af te spelen (replay). De actuele balans wordt dus altijd berekend en nooit hard opgeslagen als absolute bron van de waarheid.
De Complexiteit vs. De Winst
De voordelen van dit systeem zijn fenomenaal. Het biedt een 100% onweerlegbare, cryptografische audit-trail (verplicht in finance). Ontwikkelaars kunnen met ‘Time-Travel Debugging’ het systeem letterlijk terugspoelen naar de status van een object op een exacte datum drie jaar geleden. Bovendien stelt het bedrijven in staat om achteraf (met terugwerkende kracht) nieuwe rapportagesystemen te introduceren (Materialised Views) die de volledige historische Event Stream analyseren.
Echter, CQRS en Event Sourcing introduceren een extreme mate van complexiteit, zoals Eventual Consistency, het omgaan met falende netwerken (saga’s), en het ‘upgraden’ van events als de structuur wijzigt (event versioning). Het is een architectuur gereserveerd voor complexe bedrijfsdomeinen die falen met standaard relationele modellen. Ontdek architectuur-strategieën op AG Connect.
Volgende: Go (Golang): De Backend Taal voor High-Performance Cloud Infrastructuur
