3.0 Inleiding op deel 3: Systemen
Architectuur is de verzameling beslissingen die duur zijn om terug te draaien. Hoe splits je een systeem in delen? Hoe praten die delen met elkaar? Hoe wordt de data gemodelleerd? En hoe gedraagt het geheel zich onder belasting en bij falen? Deel 3 gaat over het bewust nemen van die beslissingen. In een klein team kan architectuur in een paar hoofden leven en onderweg evolueren. In een grote organisatie (honderden engineers, tientallen teams, systemen die de loopbaan van de mensen die ze bouwen zullen overleven) wordt architectuur datgene wat iedereen gecoördineerd houdt. Wanneer ze helder is, bewegen teams onafhankelijk zonder te botsen. Wanneer ze vaag is, wordt elke afhankelijkheid tussen teams een onderhandeling en elk incident een archeologieproject.
De inzet is het hoogst bij onderneming en overheid. Een belastingengine, een uitkeringsplatform, een nationaal gezondheidsdossier of het kerngrootboek van een bank is langlevend, zwaar gereguleerd, gedeeld over afdelingen en verantwoording verschuldigd aan het publiek. De beslissingen die je vandaag neemt over koppeling, data-eigenaarschap en kwaliteitsattributen bepalen wat mogelijk is voor een decennium of meer. Toezichthouders en auditors verwachten steeds vaker gedocumenteerde, verdedigbare architectuur, met echt bewijs dat betrouwbaarheid, beveiliging, privacy en duurzaamheid zijn ingebouwd en niet achteraf zijn vastgeschroefd. De falen die de krantenkoppen halen zijn architectuurfalen: portalen die bezwijken op de lanceringsdag, indiensystemen die bij de deadline in een time-out lopen, migraties die records kwijtraken of dubbel tellen.
Dit deel begint met de duurzame fundamenten, gaat via concrete structurele keuzes naar de werkelijkheid van distributie, data en schaal en sluit af met het moeilijkste probleem dat de meeste grote organisaties werkelijk hebben: de systemen moderniseren die ze al draaien. De rode draad: goede architectuur is een reeks bewuste afwegingen, geen modieuze standaard.
Hoofdstukken in dit deel
3.1 Architectuurfundamenten. De duurzame gereedschappen die modes in technologie overleven: kwaliteitsattributen (de “-iteiten”), architectonisch significante vereisten, fitness functions (geautomatiseerde tests die een gekozen architectuurkwaliteit bewaken) en evolutionaire architectuur, lichte documentatie met het C4-model (geneste architectuurdiagrammen op vier zoomniveaus) en arc42 (een sjabloon voor architectuurdocumentatie), en gestructureerde afwegingsanalyse.
3.2 Architectuurstijlen en -patronen. Een overzicht van de grote systeemvormen, van monoliet via microservices, gebeurtenisgedreven architecturen met CQRS (Command Query Responsibility Segregation, dat de leesmodellen van de schrijfmodellen scheidt) en event sourcing (toestand opslaan als een append-only log van gebeurtenissen), service mesh (een specifieke infrastructuurlaag voor communicatie tussen services) en gateways, serverless, en hexagonale en cleane architectuur, met richtlijnen over wanneer elk past, gekaderd door de wet van Conway (systemen neigen de communicatiestructuur van de organisatie die ze bouwt te weerspiegelen).
3.3 Gedistribueerde systemen. De harde waarheden die verschijnen zodra je een netwerkgrens overschrijdt (onbetrouwbare netwerken, gedeeltelijk falen, geen gedeelde klok) en de standaardverdedigingen: redeneren over consistentie, idempotentie (een bewerking veilig te herhalen maken), herhalingen met backoff, circuit breakers (die stoppen met het aanroepen van een falende afhankelijkheid), sagas (reeksen lokale transacties met compenserende terugdraaistappen) en gedistribueerde observeerbaarheid.
3.4 Data-architectuur en opslag. Hoe data wordt gemodelleerd, opgeslagen, consistent gehouden en op schaal snel geserveerd: de grote opslagparadigma’s en wanneer je welke gebruikt, polyglot persistence (meerdere gespecialiseerde datastores in één systeem gebruiken), schema-evolutie en migratie, caching en CDN’s (content delivery networks), en transacties en gelijktijdigheid onder belasting.
3.5 Schaalbaarheid, prestaties en veerkracht. Drie aparte kwaliteiten die worden ingebouwd in plaats van achteraf aangebracht: horizontaal en verticaal schalen, statelessness en sharding (data op een sleutel over machines splitsen), load balancing en autoscaling, prestatiebudgetten, veerkrachtpatronen en chaos engineering, en disaster recovery over meerdere regio’s gekaderd door RTO (recovery time objective) en RPO (recovery point objective).
3.6 Legacy-modernisering. De incrementele patronen die werkelijk werken, wurgvijg (een nieuw systeem rond het oude laten groeien tot het oude kan worden uitgefaseerd) en branch by abstraction (een component vervangen achter een interface op de hoofdlijn van ontwikkeling), plus risicobeoordeling van legacy, beheer van mainframe en COBOL (Common Business-Oriented Language), datamigratie en dubbel draaien, en hoe je de verleiding van de grote herschrijving weerstaat die de duurste falen van het vak oplevert.
3.7 Softwareonderhoud. De dominante fase van de softwarelevensduur: correctief, adaptief, perfectief en preventief onderhoud, programmabegrip en reengineering, en ontwerpen voor onderhoudbaarheid zodat langlevende systemen betaalbaar te wijzigen blijven.
3.8 Interoperabiliteit en open standaarden. Systemen ontwerpen die samenwerken via open standaarden in plaats van maatwerkintegraties: technische, syntactische en semantische interoperabiliteit, domeinstandaarden zoals FHIR in de gezondheidszorg en de kosten van propriëtaire afhankelijkheid.
3.9 Systems engineering. Complexe systemen van begin tot eind ontwikkelen, vaak met combinatie van software, hardware, mensen en processen: levenscyclus, toewijzing en traceerbaarheid van vereisten, interfaces, integratie en verificatie en validatie.
3.10 Embedded en realtimesystemen. Software voor apparaten onder strakke beperkingen: realtimegedrag en determinisme, een RTOS of bare-metalfirmware, beperkt geheugen en stroom, hardware-interactie en veiligheidskritieke standaarden.
3.11 Cloudarchitectuur. Ontwerpen voor de cloud in plaats van een datacenter lift-and-shiften: servicemodellen en serverless, regio’s en beschikbaarheidszones als faaldomeinen, het gedeeldeverantwoordelijkheidsmodel, afwegingen rond beheerde diensten en afhankelijkheid, multi-cloud en hybride wanneer ze hun complexiteit verdienen, en kostbewust, goed gearchitectureerd ontwerp.
3.12 Gebeurtenisgedreven architectuur en berichtenuitwisseling. Systemen bouwen die communiceren door gebeurtenissen te produceren en erop te reageren: wachtrijen tegenover duurzame streams, choreografie tegenover orkestratie, event sourcing en CQRS waar ze hun plek verdienen, sagas voor gedistribueerde transacties, leveringsgaranties en idempotentie en de patronen die asynchrone stromen betrouwbaar houden.
3.13 Netwerken en connectiviteit. De netwerken waarmee een applicatie-engineer werkelijk te maken heeft: DNS, TCP en de evolutie van HTTP, TLS-terminatie, load balancing en reverse proxies, contentlevering en edge, servicediscovery en service mesh, en de time-outs, herhalingen en circuit breakers die de onbetrouwbaarheid van het netwerk overleefbaar maken.
3.14 Multi-tenancy en SaaS-architectuur. Veel klanten vanuit één software-instantie bedienen zonder dat ze elkaar zien of uithongeren: het spectrum van isolatie tegenover efficiëntie, datapartitionering, quota per tenant tegen luidruchtige buren, tenantlevenscyclus en kostentoerekening.
3.15 Caching en contentlevering. Een beetje veroudering inruilen voor grote winst in latentie, belasting en kosten over de cachehiërarchie (client, edge en CDN, reverse proxy, applicatie en datastore), terwijl cache-invalidatie en bescherming tegen stampedes als eersteklas ontwerp worden behandeld.
3.16 API-gateways en service mesh. Noord-zuidverkeer afhandelen bij een API-gateway (routering, authenticatie, ratelimiting, compositie) en oost-westverkeer via een service mesh (mutual TLS, verkeersverschuiving, herhalingen, observeerbaarheid), en beslissen wanneer een mesh zijn complexiteit verdient.
3.17 Zoeken en informatieopvraging. Zoeken behandelen als eersteklas systeem, van de omgekeerde index en relevantieranking tot queryinterpretatie, facettering en vector- en hybride opvraging, met echte relevantie-evaluatie in plaats van gokwerk.
Hoe deze hoofdstukken samenhangen
De hoofdstukken bouwen op elkaar voort in volgorde. Hoofdstuk 3.1 geeft je het vocabulaire (kwaliteitsattributen en afwegingsanalyse) dat elk later hoofdstuk gebruikt. De “-iteiten” die het noemt zijn precies wat hoofdstukken 3.4 en 3.5 concreet maken. Hoofdstuk 3.2 zet die fundamenten om in structurele keuzes, en de meer gedistribueerde stijlen die het onderschrijft (microservices, gebeurtenisgedreven, service mesh) brengen de kosten die hoofdstuk 3.3 je leert te beheren. Hoofdstukken 3.3, 3.4 en 3.5 leunen zwaar op elkaar: distributie dwingt de consistentie- en duurzaamheidsbeslissingen van data-architectuur af, en samen vormen distributie en data wat voor schaalbaarheid en veerkracht je werkelijk kunt bereiken. Hoofdstuk 3.6 sluit de cirkel, omdat de meeste grote organisaties niet op een blanco pagina bouwen: ze laten systemen van registratie evolueren die elke keuze beperken die de eerdere hoofdstukken beschrijven.
Deel 3 reikt ook naar buiten. Hoofdstuk 3.2 put uit de ontwerpprincipes en Domain-Driven Design van hoofdstuk 2.2 om goede servicegrenzen te vinden. De operationele disciplines die deze systemen draaiend houden leven in deel 9: site reliability engineering (hoofdstuk 9.1) en observeerbaarheid (hoofdstuk 9.2) zijn waar architectonische veerkracht in productie wordt bewezen. De beveiligings- en privacy-eigenschappen die toezichthouders eisen worden hier ontworpen maar uitgewerkt in deel 4, en de platform- en leveringspraktijken in deel 8 bepalen of een architectuur werkelijk door veel teams tegelijk kan worden opgeleverd en beheerd.