Software Architecture Flashcards
Software-architectuur
De structuur of structuren van een systeem, inclusief de componenten, hun relaties, en de richtlijnen en principes die het ontwerp en de evolutie van het systeem sturen.
Component
Een zelfstandig functioneel onderdeel van een softwaretoepassing, zoals een module, service of microservice. Componenten hebben duidelijke verantwoordelijkheden en communiceren via goed gedefinieerde interfaces.
Interface
Een punt waar twee systemen, componenten of modules met elkaar communiceren. Interfaces definiëren hoe de interactie plaatsvindt, zoals via een API of een message queue.
Layered Architecture
Een architectuurpatroon waarbij het systeem is georganiseerd in lagen (bijvoorbeeld presentatie, logica en data). Elke laag heeft een specifieke rol en communiceert alleen met aangrenzende lagen.
Microservices
Een architectuurstijl waarbij een applicatie wordt opgebouwd uit kleine, zelfstandige services die onafhankelijk kunnen worden ontwikkeld, ingezet en geschaald.
Design Patterns
Herbruikbare oplossingen voor veelvoorkomende ontwerpproblemen in softwareontwikkeling. Voorbeelden zijn het Singleton-, Factory-, en Observer-patroon.
Service-Oriented Architecture (SOA)
Een architectuurstijl waarbij applicaties worden opgebouwd uit herbruikbare en loosely coupled services. Deze services kunnen verschillende technologieën gebruiken en communiceren via een gestandaardiseerd protocol.
Scalability
Het vermogen van een systeem om te groeien en prestaties te behouden naarmate de belasting toeneemt. Dit kan horizontaal (extra servers toevoegen) of verticaal (meer resources toevoegen aan een server).
Coupling en Cohesion
Coupling: De mate waarin componenten afhankelijk zijn van elkaar. Lage coupling is wenselijk voor flexibiliteit.
Cohesion: Hoe goed de verantwoordelijkheden binnen een component samenhangen. Hoge cohesie is wenselijk voor eenvoud en onderhoudbaarheid.
Architectural Styles
Verschillende manieren om een systeem te organiseren, zoals:
Client-Server: Een centrale server biedt diensten aan meerdere clients.
Event-Driven: Componenten communiceren via events (asynchroon).
REST: Een stijl voor webservices die gebruikmaakt van HTTP-methoden.
Domain-Driven Design (DDD)
Een aanpak waarbij het ontwerp van software wordt geleid door de behoeften van de business. Het focust op het modelleren van de domeinlogica en het gebruik van een gedeeld vocabulaire.
Non-Functionele Eisen (NFRs)
Kwaliteitseisen van een systeem, zoals performance, beveiliging, betrouwbaarheid en schaalbaarheid. Ze beïnvloeden de keuzes in de architectuur sterk.
Deployment Architecture
De configuratie van softwarecomponenten op hardware en infrastructuur. Het bepaalt hoe een systeem wordt geïmplementeerd en uitgevoerd in productieomgevingen.
Monolith
Een monolithische architectuur is een systeem waarin alle onderdelen (zoals gebruikersinterface, logica en data) geïntegreerd zijn in één enkele applicatie of codebase.
Kenmerken:
Eén codebase en deployment-eenheid.
Componenten zijn sterk gekoppeld.
Eenvoudige ontwikkeling en testing bij kleinere projecten.
Voordelen:
Minder complexe infrastructuur.
Eenvoudig te implementeren en debuggen.
Nadelen:
Schaalbaarheid is moeilijker, vaak alleen verticaal.
Moeilijker onderhoudbaar naarmate het systeem groeit.
Distributed Systems
Een gedistribueerd systeem bestaat uit meerdere zelfstandige componenten (services of nodes) die samen functioneren om een applicatie te draaien. Deze componenten draaien op verschillende machines of locaties en communiceren via netwerken.
Kenmerken:
Componenten zijn losjes gekoppeld.
Kan fysiek verspreid zijn over meerdere servers of zelfs datacenters.
Vaak gebaseerd op communicatieprotocollen zoals REST, gRPC, of message queues.
Voordelen:
Horizontale schaalbaarheid: meer servers toevoegen om de belasting te verdelen.
Fouttolerantie: bij falen van een component blijft de rest functioneren.
Geschikt voor grote, complexe systemen.
Nadelen:
Hogere complexiteit door gedistribueerde infrastructuur.
Communicatie tussen componenten kan leiden tot vertragingen of fouten.
Moeilijker te debuggen en testen.
Technische opdeling
Hierbij wordt de architectuur opgedeeld op basis van technische componenten, zoals een frontend, backend, database, en andere infrastructuur.
Elke laag of module heeft een specifieke rol in het systeem, zoals presentatie, logica, of opslag.
Voordelen: Logische scheiding van verantwoordelijkheden, betere onderhoudbaarheid.
Nadeel: Kan minder goed aansluiten bij de businesscontext.
Opdeling in Domeinen
Dit wordt vaak “Domain-Driven Design” (DDD) genoemd. De architectuur wordt georganiseerd rondom de domeinlogica van de applicatie, waarbij elk domein een specifieke businesscontext vertegenwoordigt.
Voorbeeld: Voor een webshop kunnen de domeinen bestaan uit Orders, Klanten, en Betalingen.
Voordeel: Sluit beter aan bij de businessvereisten en gebruikerstaken.
Nadeel: Vereist een diep begrip van het domein en kan complexer zijn om op te zetten.
Synchrone communicatie
Berichten worden direct uitgewisseld en verwerkt. Beide partijen wachten op elkaar, bijvoorbeeld bij een HTTP-request.
Voordeel: Eenvoudig te begrijpen en implementeren.
Nadeel: Kan vertragingen veroorzaken als één partij traag reageert.
Asynchrone communicatie
Berichten worden verzonden en verwerkt op verschillende tijdstippen. Dit gebeurt vaak via queues of events.
Voordeel: Flexibeler en beter bestand tegen netwerkproblemen.
Nadeel: Complexer om te implementeren en foutopsporing kan lastiger zijn.
Wat zijn de acht belangrijkste verwachtingen van een software architect?
- Make architecture decisions
- Continually analyze the architecture
- Keep current with latest trends
- Ensure compliance with decisions
- Diverse exposure and experience
- Have business domain knowledge
- Possess interpersonal skills
- Understand and navigate politics
Wat is een uitdaging bij het definiëren van software architectuur?
Het verandert continu door technologische vooruitgang, zoals microservices en DevOps.
Welke elementen omvat software architectuur?
Structuur, architectuurkarakteristieken (”-ilities”), architectuurbeslissingen, en designprincipes.
Waarom is alleen het benoemen van een architectuurstijl (zoals microservices) niet voldoende?
Omdat ook de onderliggende beslissingen en eigenschappen belangrijk zijn.
Wat is de belangrijkste taak van een software architect bij architectuurbeslissingen?
Het vaststellen van richtlijnen en regels voor hoe technologie wordt gebruikt.
Wat is “architectural decay”?
Het proces waarbij een architectuur minder efficiënt wordt door veranderingen in technologie en bedrijfsbehoeften.
Waarom is kennis van het bedrijfsdomein belangrijk voor een software architect?
Het helpt bij het begrijpen en ontwerpen van oplossingen die aansluiten bij zakelijke eisen.
Wat zijn de twee wetten van software architectuur?
1) Alles in softwarearchitectuur is een trade-off.
2) Waarom is belangrijker dan hoe.
Wat zijn fitness functions in evolutionaire architecturen?
Mechanismen, zoals tests of monitoring, om ervoor te zorgen dat belangrijke architectuurkenmerken intact blijven.
Wat is een cruciale vaardigheid van een software architect?
Het omgaan met politiek binnen de organisatie en het navigeren van weerstand tegen veranderingen.
Welke impact heeft DevOps op software architectuur?
Het bevordert samenwerking tussen ontwikkelaars en operations, waardoor schaalbaarheid en betrouwbaarheid verbeteren.
Wat is architecturaal denken?
Het bekijken van softwareprojecten vanuit een architectonisch perspectief, met focus op structurele, technische en zakelijke aspecten.
Wat zijn de vier belangrijke aspecten van architecturaal denken?
1) Verschil tussen architectuur en design,
2) Technische breedte vs. diepte,
3) Trade-offs analyseren,
4) Begrijpen van zakelijke drijfveren.
Wat is het verschil tussen architectuur en design?
Architectuur gaat over structurele beslissingen en “-ilities,” terwijl design focust op de implementatie van componenten.
Wat is de kennispiramide voor een architect?
1) Stuff you know (expertise),
2) Stuff you know you don’t know (bewust onbekend),
3) Stuff you don’t know you don’t know (onbewust onbekend).
Wat is het “Frozen Caveman Anti-Pattern”?
Wanneer een architect vasthoudt aan verouderde ideeën door negatieve ervaringen uit het verleden.
Hoe moeten architecten omgaan met nieuwe technologieën?
Nieuwe technologieën blijven verkennen en objectief naar oplossingen kijken.
Wat zijn tips om als architect hands-on te blijven?
POC’s maken, technische schulden oplossen, bugfixes doen, automatiseringstools ontwikkelen, en code reviews uitvoeren.
Wat is de belangrijkste rol van een architect in samenwerking met ontwikkelaars?
Mentoren, coachen en bidirectioneel communiceren om architectuurprincipes goed te implementeren.
Wat betekent architecturaal denken in de praktijk?
Brede technische kennis hebben, samenwerken met teams, trade-offs analyseren, en oplossingen kiezen op basis van zakelijke en technische behoeften.
Wat is modulariteit in software?
Het logisch groeperen van gerelateerde code in modules om complexiteit te verminderen en onderhoud te vergemakkelijken.
Wat zijn de drie metrieken om modulariteit te meten?
Cohesie, koppeling en connascence.
Wat is cohesie in modulariteit?
De mate waarin onderdelen van een module logisch met elkaar verbonden zijn.
Wat is koppeling in modulariteit?
De mate waarin modules afhankelijk zijn van elkaar.
Wat is connascence?
Een verfijnde kijk op koppeling, waarbij modules samen moeten veranderen om de correctheid van het systeem te behouden.
Wat is het verschil tussen modules en componenten?
Modules zijn logische groeperingen van code, terwijl componenten fysieke implementaties zijn die kunnen worden hergebruikt.
Wat zijn de voordelen van modulariteit in software?
Schaalbaarheid, onderhoudbaarheid en begrijpelijkheid van systemen verbeteren.
Waarom is modulariteit essentieel voor softwarearchitectuur?
Het maakt complexe systemen beter beheersbaar en aanpasbaar aan verandering.
Wat zijn architectuurkenmerken?
Belangrijke ontwerpcriteria die beschrijven hoe een systeem moet presteren en waarom bepaalde ontwerpkeuzes zijn gemaakt.
Aan welke drie criteria moet een architectuurkenmerk voldoen?
1) Niet-domeinspecifiek,
2) Beïnvloedt een structureel aspect van het ontwerp,
3) Cruciaal voor het succes van de applicatie.
Noem drie voorbeelden van operationele architectuurkenmerken.
Beschikbaarheid, prestaties, schaalbaarheid.
Noem drie voorbeelden van structurele architectuurkenmerken.
Uitbreidbaarheid, onderhoudbaarheid, portabiliteit.
Noem drie voorbeelden van cross-cutting architectuurkenmerken.
Beveiliging, toegankelijkheid, privacy.
Wat beschrijven ISO-standaarden voor architectuurkenmerken?
Definities voor kenmerken zoals prestaties, compatibiliteit, gebruiksvriendelijkheid, beveiliging, en onderhoudbaarheid.
Wat is een veelvoorkomende trade-off bij architectuurkenmerken?
Het verbeteren van beveiliging kan een negatief effect hebben op prestaties.
Waarom streven architecten naar de “minst slechte architectuur”?
Omdat een perfecte architectuur onhaalbaar is en er altijd trade-offs zijn tussen kenmerken.
Wat is het doel van iteratief ontwerpen in softwarearchitectuur?
Aanpassingen aan de architectuur vergemakkelijken en flexibiliteit behouden.
Wat zijn architectuurkenmerken?
Belangrijke ontwerpcriteria zoals schaalbaarheid, prestaties en veiligheid, die de basis vormen voor architectonische keuzes.
Wat zijn de drie manieren om architectuurkenmerken te identificeren?
1) Extractie uit domeinproblemen,
2) Extractie uit vereisten,
3) Gebruik van impliciete domeinkennis.
Hoe vertalen architecten domeinproblemen naar architectuurkenmerken?
Door zakelijke termen zoals “gebruikerssatisfactie” te koppelen aan technische termen zoals prestaties of beschikbaarheid.
Wat is het verschil tussen schaalbaarheid en elasticiteit?
Schaalbaarheid: Meer gebruikers kunnen ondersteunen zonder prestatieverlies.
Elasticiteit: Snel reageren op pieken in verkeer.
Wat is het verschil tussen een designbeslissing en een architectuurbeslissing?
Designbeslissing: Specifieke implementatiedetails zoals een design pattern.
Architectuurbeslissing: Structurele keuzes zoals een microkernel-architectuur.
Wat is een belangrijk doel bij het identificeren van architectuurkenmerken?
Een balans vinden tussen prestaties, schaalbaarheid, veiligheid en flexibiliteit.
Wat zijn fitness functions in softwarearchitectuur?
Automatische checks die ervoor zorgen dat architectuurkenmerken worden nageleefd.
Noem drie voorbeelden van fitness functions.
1) Cyclische afhankelijkheden checken,
2) Layered architecture controleren,
3) Chaos engineering tests.
Waarom zijn fitness functions belangrijk?
Ze automatiseren governance, voorkomen handmatig toezicht en garanderen een balans tussen snelheid en kwaliteit.
Wat is connascence in softwarearchitectuur?
Het concept dat twee componenten gekoppeld zijn, zodat een wijziging in de ene een aanpassing in de andere vereist.
Wat zijn de twee soorten connascence?
1) Statisch: Gedefinieerd door code-analyse, zoals gedeelde klassen.
2) Dynamisch: Ontstaat tijdens runtime, bijvoorbeeld via synchronisatie.
Wat is het verschil tussen libraries en services als componenten?
Libraries draaien in hetzelfde geheugen en zijn compile-time afhankelijkheden, terwijl services losstaan en communiceren via protocollen zoals REST.
Wat zijn de twee stijlen van architecture partitioning?
1) Layered Monolith (technische lagen),
2) Modular Monolith (domeinen of workflows).
Wat is een voordeel van een gedistribueerde architectuur?
Geschikt voor systemen met verschillende architectuurkenmerken zoals schaalbaarheid en elasticiteit.
Wanneer zou je kiezen voor een monolithische architectuur?
Als het systeem uniforme architectuurkenmerken heeft en uit één quantum bestaat.
Wat is de impact van componenten op modulariteit?
Componenten maken systemen opdeelbaar in begrijpelijke, zelfstandig inzetbare eenheden, wat modulariteit vergroot.
Wat is een belangrijke conclusie over component-gebaseerd denken?
Architecten moeten continu itereren en een balans vinden tussen granulariteit, afhankelijkheden en architectuurkenmerken.
Wat beschrijven architectuurstijlen en -patronen?
Gestructureerde relaties tussen componenten binnen een systeem, zoals Layered Architecture of Microservices.
Wat is het anti-pattern Big Ball of Mud?
Een ongeorganiseerd, chaotisch systeem zonder duidelijke structuur, wat leidt tot slechte aanpasbaarheid en prestaties.
Wat is een Client/Server Architecture?
Een twee-lagen architectuur waarbij een client (frontend) communiceert met een server (backend), zoals een webbrowser en een webserver.
Wat zijn de drie lagen in een Three-Tier Architecture?
Frontend, applicatielaag, en databank.
Wat is het verschil tussen monolithische en gedistribueerde architecturen?
Monolithische architecturen hebben één deploymenteenheid, terwijl gedistribueerde architecturen bestaan uit meerdere onafhankelijke deploymentunits.
Noem een voordeel en een nadeel van een gedistribueerde architectuur.
Voordeel: Hogere schaalbaarheid en prestaties.
Nadeel: Complex beheer en latentieproblemen.
Wat zijn uitdagingen bij gedistribueerde architecturen?
Distributed logging, distributed transactions, en contract maintenance/versioning.
Wat is de belangrijkste focus bij het leren van gedistribueerde architecturen?
Begrijp de fundamentele patronen, de fallacies of distributed computing, en uitdagingen zoals logging en transacties.
Wat is Layered Architecture?
Definitie: Een n-tiered architecture waarbij componenten worden gegroepeerd op technische rol (bijv. presentatie, business logic).
Waarom populair?: Simpliciteit, lage kosten, en bekendheid binnen organisaties.
Wat zijn de vier lagen in Layered Architecture?
- Presentation Layer: UI en communicatie met gebruikers.
- Business Layer: Voert bedrijfsregels uit.
- Persistence Layer: Beheert toegang tot data.
- Database Layer: Slaat gegevens op.
Wat is Separation of Concerns in Layered Architecture?
Elke laag heeft een specifieke verantwoordelijkheid, wat gespecialiseerde focus en eenvoud in onderhoud mogelijk maakt.
Wat is het verschil tussen Closed en Open Layers?
Closed Layers: Verzoeken doorlopen elke laag → betere isolatie.
Open Layers: Verzoeken kunnen lagen overslaan → meer flexibiliteit, maar ook complexiteit.
Wat zijn de voordelen van Layered Architecture?
- Eenvoud en lage kosten.
- Gemakkelijk te begrijpen en implementeren.
- Goed startpunt voor voorlopige architectuur.
Wat zijn de nadelen van Layered Architecture?
- Slechte schaalbaarheid: Moeilijk om onderdelen onafhankelijk te schalen.
- Beperkte testbaarheid: Wijzigingen vereisen herdeployments.
- Lage fouttolerantie: Eén fout kan het hele systeem beïnvloeden.
Wanneer is Layered Architecture geschikt?
- Kleine en eenvoudige applicaties.
- Snel ontwikkelen zonder duidelijke vereisten.
- Beperkte tijd en budgetten.
Wat is de Pipeline Architecture Style?
Een architectuurstijl waarin functionaliteit wordt opgesplitst in discrete onderdelen (filters) die data verwerken via unidirectionele communicatiekanalen (pipes).
Wat zijn de componenten van de Pipeline Architectuur?
- Pipes: Kanalen voor unidirectionele communicatie.
- Filters: Stateless componenten met specifieke taken:
* Producer: Startpunt van het proces.
* Transformer: Transformeert en stuurt data door.
* Tester: Controleert data op criteria.
* Consumer: Eindpunt voor opslag of presentatie.
- Filters: Stateless componenten met specifieke taken:
Wat zijn voorbeelden van de Pipeline Architectuur?
- ETL-tools: Data migratie en transformatie.
- Apache Kafka: Data ingestie en verwerking.
- Unix-pipes: Bijvoorbeeld cat file.txt | grep “error” | sort.
Wat zijn de voordelen van de Pipeline Architectuur?
- Eenvoud en modulariteit: Elk filter kan onafhankelijk worden aangepast of vervangen.
- Lage kosten: Eenvoudige implementatie en onderhoud.
- Herbruikbaarheid: Filters kunnen worden gecombineerd en opnieuw gebruikt.
Wat zijn de nadelen van de Pipeline Architectuur?
- Beperkte schaalbaarheid:
- Moeilijk om afzonderlijke filters te schalen.
- Multithreading nodig voor schaalbaarheid.
- Lage fouttolerantie:
* Fouten in één filter kunnen de hele pipeline verstoren.
* Herstellen duurt lang bij crashes. - Gemiddelde betrouwbaarheid:
* Kwetsbaar door monolithische aard.
Wanneer is de Pipeline Architectuur geschikt?
- Kleine tot middelgrote applicaties met lineaire dataverwerking.
- ETL-processen en data-integratie.
- Toepassingen waarbij lage kosten en eenvoud belangrijker zijn dan schaalbaarheid en fouttolerantie.
Wat is de conclusie over de Pipeline Architectuur?
- Sterk: Voor eenvoudige, lineaire processen en systemen met lage kosten.
- Zwak: Voor grootschalige, fouttolerante of elastische systemen zijn meer modulaire en gedistribueerde architecturen beter.
Wat is de Microkernel Architectuur?
- Een architectuurstijl met een kernsysteem en plug-ins.
- Ideaal voor productgebaseerde software zoals IDE’s en browsers, of zakelijke toepassingen die uitbreidbaar en aanpasbaar moeten zijn.
Wat is het doel van het kernsysteem in de Microkernel Architectuur?
- Het kernsysteem bevat alleen de minimale functionaliteit die nodig is om het systeem te laten werken.
- Voorbeeld: In Eclipse is de kern slechts een teksteditor, terwijl plug-ins extra functies toevoegen.
Wat zijn plug-ins in de Microkernel Architectuur?
- Zelfstandige modules die extra functionaliteit toevoegen.
- Plug-ins kunnen runtime (dynamisch) of compile-time (statisch) worden toegevoegd.
Wat zijn de voordelen van de Microkernel Architectuur?
- Uitbreidbaarheid: Nieuwe functionaliteit toevoegen via plug-ins.
- Isolatie: Complexe logica wordt naar plug-ins verplaatst.
- Modulariteit: Plug-ins bevatten hun eigen logica en soms een eigen database.
Wat zijn de nadelen van de Microkernel Architectuur?
- Monolithische beperkingen:
- Plug-ins zijn afhankelijk van het kernsysteem, wat schaalbaarheid beperkt.
2. Complexiteit bij remote plug-ins: - Externe plug-ins verhogen kosten en risico’s.
3. Beperkte schaalbaarheid en fault tolerance: - Afhankelijkheid van het kernsysteem belemmert prestaties bij hoge belasting.
- Plug-ins zijn afhankelijk van het kernsysteem, wat schaalbaarheid beperkt.
Wat zijn enkele voorbeelden van de Microkernel Architectuur?
- Eclipse IDE: Plug-ins voor extra functionaliteit zoals versiebeheer of debugging.
- Browsers: Zoals Chrome of Firefox, met extensies als plug-ins.
- Verzekeringsclaims: Jurisdictie-specifieke regels in plug-ins.
- Belastingsoftware: Elk belastingformulier als een plug-in.
Wanneer is de Microkernel Architectuur geschikt?
- Productgebaseerde applicaties: Zoals IDE’s, browsers, en belastingsoftware.
- Applicaties met veel aanpasbare functionaliteit: Bijvoorbeeld modules voor specifieke regels of workflows.
Wat is de conclusie over de Microkernel Architectuur?
- Sterk: Uitbreidbaarheid, modulariteit en lage kosten maken het ideaal voor kleinere systemen en toepassingen.
- Zwak: Beperkte schaalbaarheid en fault tolerance maken het minder geschikt voor grootschalige, gedistribueerde systemen.
Wat is de Service-Based Architectuur?
- Een hybride architectuurstijl tussen monolithische en microservicesarchitecturen.
- Ontworpen voor domeingerichte applicaties met een focus op eenvoud, agility en testbaarheid.
Wat is de topologie van een Service-Based Architectuur?
- User Interface:
- Afzonderlijk gedeployed, communiceert met services via REST, messaging of RPC.
2. Coarse-Grained Services: - Domeinspecifieke services (bijv. OrderService, CustomerService).
- Elke service heeft een API-laag, business logica, en persistence.
3. Monolithische Database: - Eén gedeelde database voor alle services, ondersteunt traditionele ACID-transacties.
- Afzonderlijk gedeployed, communiceert met services via REST, messaging of RPC.
Wat zijn voorbeelden van domeingerichte services in deze architectuur?
- OrderService: Beheert bestellingen.
- CustomerService: Houdt klantgegevens bij.
- QuotingService: Genereert offertes in een recycling systeem.
Wat zijn de voordelen van een Service-Based Architectuur?
- Agility: Snelle aanpassingen binnen individuele services.
- Testbaarheid: Eenvoudiger testen dankzij beperkte service scope.
- Deployability: Frequent en risicoloos deployen van afzonderlijke services.
- Fault Tolerance: Fouten in één service beïnvloeden andere services niet.
- Schaalbaarheid: Specifieke services kunnen onafhankelijk worden geschaald.
Wat zijn de nadelen van een Service-Based Architectuur?
- Database Coupling:
- Gedeelde databaseschema’s kunnen wijzigingen risicovol maken.
2. Beperkte Elasticiteit: - Coarse-grained services benutten resources minder efficiënt dan microservices.
3. Minder Granulariteit: - Minder flexibel en schaalbaar dan fijnmazige microservices.
- Gedeelde databaseschema’s kunnen wijzigingen risicovol maken.
Voor welke use cases is een Service-Based Architectuur geschikt?
- Elektronica Recycling Systeem:
- Services zoals Quoting, Receiving, Assessment, en Recycling zijn logisch gescheiden.
- Fouttolerantie door klantgerichte services te schalen.
2. Bedrijfsapplicaties: - Bijvoorbeeld claimsverwerking in verzekeringen of financiële rapportages.
Wanneer kies je voor een Service-Based Architectuur?
- Wanneer flexibiliteit en schaalbaarheid belangrijk zijn, maar zonder de complexiteit van microservices.
- Voor domeingerichte ontwerpen met logische opsplitsing op hoog niveau.
- Als traditionele ACID-transacties vereist zijn en BASE-consistentie niet voldoet.
Wat is een belangrijk nadeel van gedeelde databases in Servive-Based architectuur?
Database Coupling: Wijzigingen aan het schema kunnen andere services beïnvloeden en complex maken.
Wat is de conclusie over de Service-Based Architectuur?
Een uitstekende keuze voor middelgrote domeingerichte systemen.
* Combineert eenvoud, lage kosten en agility met voldoende flexibiliteit en schaalbaarheid voor veel zakelijke toepassingen.
* Minder geschikt voor zeer complexe, grootschalige applicaties waar meer fijnmazigheid nodig is.
Wat is een Event-Driven Architectuur?
- Een asynchrone en gedistribueerde architectuurstijl.
- Gebruikt losgekoppelde eventprocessoren om gebeurtenissen te verwerken.
- Ideaal voor schaalbare en prestatiegerichte toepassingen.
Wat zijn de twee topologieën in een Event-Driven Architectuur?
- Broker Topologie:
- Geen centrale controle, berichten worden via een message broker verwerkt.
- Geschikt voor eenvoudige workflows met hoge schaalbaarheid.
- Mediator Topologie:
* Centrale controle via een event-mediator die workflows coördineert.
* Geschikt voor complexe workflows met foutafhandeling.
Wat zijn de voordelen van een Broker Topologie? (Event-Driven)
- Hoge decoupling: Componenten zijn onafhankelijk.
- Schaalbaarheid: Eenvoudig nieuwe processoren toevoegen.
- Prestatiegericht: Minimale latentie door directe verwerking.
Wat zijn de nadelen van een Broker Topologie? (Event-Driven)
- Geen workflowcontrole.
- Beperkte foutafhandelingsmogelijkheden.
- Moeilijk te herstellen bij fouten.
Wat zijn de voordelen van een Mediator Topologie? (Event-Driven)
- Centrale workflowcontrole.
- Mogelijkheden voor foutafhandeling en herstel.
- Geschikt voor complexe processen.
Wat zijn de nadelen van een Mediator Topologie? (Event-Driven)
- Lagere schaalbaarheid dan een broker.
- Hogere koppeling tussen componenten.
- Complexer ontwerp en onderhoud.
Wat zijn de voordelen van Event-Driven Architectuur?
- Schaalbaarheid: Kan eenvoudig omgaan met grote workloads.
- Prestatiegericht: Minimaliseert latentie door asynchrone verwerking.
- Flexibiliteit: Nieuwe functionaliteit kan zonder grote aanpassingen worden toegevoegd.
- Evolutiegericht: Publiceren van gebeurtenissen ondersteunt eenvoudige uitbreiding.
- Responsiviteit: Gebruikers krijgen directe feedback.
Wat zijn de uitdagingen van Event-Driven Architectuur?
Eventual Consistency: Geen directe dataconsistentie.
* Complexe foutafhandeling: Moeilijk om workflows te herstellen.
* Moeilijk te testen: Asynchrone processen creëren complexe scenario’s.
* Hogere complexiteit: Vooral in grote systemen met hybride topologieën.
Wat zijn veelvoorkomende use cases voor EDA?
- Online Veilingen: Elk bod wordt verwerkt als een gebeurtenis.
- Retail Order Entry: Orders genereren een keten van gebeurtenissen (bijv. voorraadcontrole, verzending).
- Stock Trading: Realtime verwerking van aandelenupdates.
Wanneer gebruik je Event-Driven Architectuur?
- Voor systemen met hoge schaalbaarheidseisen en asynchrone workflows.
- Wanneer prestaties en responsiviteit cruciaal zijn.
- Niet geschikt voor systemen die sterke dataconsistentie of eenvoudige testbaarheid vereisen.
Wat is de conclusie over Event-Driven Architectuur?
- Ideaal voor gedistribueerde systemen die schaalbaar, prestatiegericht en uitbreidbaar moeten zijn.
- Keuze tussen broker (schaalbaarheid) en mediator (workflowcontrole) hangt af van de systeembehoeften.
- Uitstekende optie voor moderne, complexe systemen met veel gebeurtenissen.
Wat is Space-Based Architectuur?
- Een architectuurstijl ontworpen om schaalbaarheidsproblemen te overwinnen.
- Gebruikt in-memory data grids en asynchrone verwerking om knelpunten in traditionele webarchitecturen te elimineren.
- Ideaal voor systemen met hoge piekbelasting en variabele gebruikersvolumes.
Wat zijn de belangrijkste kenmerken van Space-Based Architectuur?
- In-memory Data Grids:
- Gegevens worden in het geheugen opgeslagen en gerepliceerd.
- Asynchrone updates voorkomen knelpunten.
- Verwerkingsunits (Processing Units):
* Bevatten applicatielogica en caches.
* Dynamisch schaalbaar. - Virtueel Middleware-systeem:
* Messaging Grid: Verzendt verzoeken.
* Processing Grid: Coördineert workflows.
* Deployment Manager: Schaal elasticiteit dynamisch. - Asynchrone Data Pumps:
* Verzenden gegevens naar de database met eventual consistency.
Wat zijn de voordelen van Space-Based Architectuur?
- Maximale Elasticiteit: Dynamisch schalen bij veranderende belasting.
- Hoge Prestaties: Verwijdert directe database-interacties.
- Schaalbaarheid: Ondersteunt miljoenen gelijktijdige gebruikers.
- Flexibiliteit: Perfect voor toepassingen met variabele gebruikerspieken.
Wat zijn de uitdagingen van Space-Based Architectuur?
- Complexiteit:
- Beheer van caches en gegevensreplicatie vereist zorgvuldigheid.
2. Testbaarheid: - Testen van schaalbaarheid is complex en kostbaar.
3. Kosten: - Hoge licentie- en infrastructuurkosten.
4. Data Collisions: - Mogelijke inconsistenties door replicatielatentie.
- Beheer van caches en gegevensreplicatie vereist zorgvuldigheid.
Wat is een typische use case voor Space-Based Architectuur?
- Concertticketing:
- Snel schalen voor piekverkoop.
- Realtime updates van tickets en zitplaatsen.
2. Online Veilingen: - Dynamisch schalen bij biedingspieken.
- Snelle verwerking voor realtime biedingen.
Wanneer gebruik je Space-Based Architectuur?
- Voor systemen met hoge elasticiteit en schaalbaarheidsvereisten.
- Geschikt voor piekbelastingstoepassingen zoals:
- Concertticketing
- Online veilingen
- Minder geschikt voor eenvoudige, goedkope applicaties vanwege kosten en complexiteit.
Wat maakt Space-Based Architectuur uniek?
- Het verwijdert de centrale database als bottleneck.
- In-memory verwerking en asynchrone updates bieden maximale prestaties.
- Dynamische schaalbaarheid maakt het ideaal voor onvoorspelbare piekbelastingen.
Wat is de conclusie over Space-Based Architectuur?
- Ideaal voor toepassingen die elasticiteit, schaalbaarheid en hoge prestaties vereisen.
- Complex en kostbaar, vooral geschikt voor veeleisende domeinen zoals piekbelasting.
- Perfect voor moderne, prestatie-intensieve systemen met variabele gebruikersvolumes.
Wat is Orchestration-Driven SOA?
- Een architectuurstijl uit de late jaren 1990, gericht op hergebruik van services en orkestratie van gedistribueerde systemen.
- Gebaseerd op een centrale orkestratiemotor die transacties coördineert en services koppelt.
Wat zijn de belangrijkste kenmerken van Orchestration-Driven SOA?
- Topologie:
- Business Services: Hoog-niveau services zoals PlaceOrder.
- Enterprise Services: Herbruikbare, fijngranulaire implementaties zoals CreateCustomer.
- Application Services: Eenmalige, domeinspecifieke services.
- Infrastructure Services: Ondersteunende services zoals monitoring en logging.
- Orkestratiemotor:
* Coördineert workflows en transacties tussen services.
* Integreert met legacy-systemen. - Berichtenstroom:
* Alle aanvragen verlopen via de centrale orkestratiemotor.
Wat zijn de voordelen van Orchestration-Driven SOA?
- Elasticiteit en Schaalbaarheid:
- Tools zoals sessiereplicatie ondersteunen schaalbaarheid.
- Integratie:
* Eenvoudige koppeling van systemen via de orkestratiemotor, inclusief legacy-software.
Wat zijn de nadelen van Orchestration-Driven SOA?
- Sterke Koppeling:
- Wijzigingen in een centrale service (bijv. Customer) hebben impact op andere services.
2. Complexiteit: - Technische partitionering maakt beheer moeilijk en versnipperd.
3. Inefficiënties: - Lagere prestaties door gedistribueerde aard en meerdere oproepen binnen de architectuur.
4. Testbaarheid: - Testen is uitdagend door afhankelijkheden en complexe workflows.
- Wijzigingen in een centrale service (bijv. Customer) hebben impact op andere services.
Wat zijn typische use cases van Orchestration-Driven SOA?
- Enterprise-systemen met complexe workflows die herbruikbaarheid en integratie vereisen.
- Legacy-systemen integreren in moderne applicaties.
Wat is de conclusie over Orchestration-Driven SOA?
- Voordelen: Herbruikbaarheid en schaalbaarheid in complexe ondernemingen.
- Nadelen: Sterke koppeling, inefficiënties en lage prestaties.
- Relevantie: Een belangrijke stap in de evolutie naar flexibelere stijlen zoals microservices.
Wat is Microservices Architecture?
- Een populaire architectuurstijl geïnspireerd door Domain-Driven Design (DDD) en bounded context.
- Focus op extreme ontkoppeling door systemen op te splitsen in kleine, onafhankelijke services die elk een specifiek domein vertegenwoordigen.
Wat is de topologie van Microservices Architecture?
- Gedecentraliseerd: Elke service draait in een eigen proces.
- Zelfvoorzienend: Bevat eigen logica en data-opslag.
- Granulariteit: Domeingericht, maar niet te klein om overmatige communicatie te voorkomen.
Welke communicatiemethoden worden gebruikt in Microservices?
- Synchroon: API-aanroepen (bijv. REST).
- Asynchroon: Evenementgestuurd via message queues.
- Choreografie: Directe communicatie tussen services zonder centrale controle.
- Orkestratie: Een mediator coördineert complexe workflows, wat koppeling introduceert.
Wat zijn de voordelen van Microservices?
- Schaalbaarheid en Elasticiteit: Services kunnen onafhankelijk schalen.
- Evolueerbaarheid: Componenten vervangen/upgraden zonder het hele systeem te beïnvloeden.
- Flexibele technologiekeuze: Teams kunnen technologieën kiezen die passen bij hun service.
Wat zijn de nadelen van Microservices?
- Prestatieproblemen: Netwerkcommunicatie is trager dan methodaanroepen in een monoliet.
- Complexiteit: Meerdere services, databases en communicatie verhogen de operationele last.
- Data-consistentie: Het vermijden van gedeelde databases vereist extra mechanismen zoals het saga-patroon.
Wanneer gebruik je Microservices Architecture?
- Wanneer schaalbaarheid, elasticiteit en evolutie essentieel zijn.
- Geschikt voor snel veranderende omgevingen en gedistribueerde systemen.
- Minder geschikt voor eenvoudige systemen door hogere complexiteit.
Wat is de conclusie over Microservices Architecture?
- Voordelen: Schaalbaar, flexibel en evolueerbaar.
- Uitdagingen: Vereist zorgvuldige afwegingen rond communicatie, transacties en complexiteit.
- Populair voor moderne systemen dankzij de focus op ontkoppeling en teamautonomie.
Wat beïnvloedt de keuze van een architectuurstijl?
- Trends in architectuur: Nieuwe stijlen ontstaan door lessen uit het verleden en technologische veranderingen.
- Contextuele factoren: Domeinvereisten, organisatorische beperkingen, en teamvaardigheden.
- Specifieke keuzes: Monolithisch versus gedistribueerd, dataopslag, en communicatievorm.
Wat zijn belangrijke trends in architectuur?
- Observaties uit het verleden: Oplossingen voor oude pijnpunten, zoals ontkoppeling.
- Ecosysteemveranderingen: Nieuwe technologieën zoals containers en Kubernetes.
- Nieuwe mogelijkheden: Paradigmawisselingen door tools zoals Docker.
- Versnelling van verandering: Snelle adoptie van nieuwe tools en methodologieën.
Wat zijn de belangrijkste contextuele factoren bij het kiezen van een architectuurstijl?
- Domeinvereisten: Begrip van operationele behoeften.
- Architectuureigenschappen: Bijvoorbeeld schaalbaarheid, prestaties, en flexibiliteit.
- Organisatorische beperkingen: Budget, cloudstrategieën, en tools.
- Team- en proceskennis: Agile volwassenheid en DevOps-capaciteiten.
Wat is het verschil tussen een monolithische en gedistribueerde architectuur?
- Monolithisch: Eén set architectuureigenschappen en meestal één database.
- Gedistribueerd: Verschillende delen met unieke eigenschappen, vaak met asynchrone communicatie.
Wat zijn de voordelen van synchrone communicatie?
- Eenvoudiger ontwerp: Minder complex om te implementeren.
- Gemakkelijker debuggen: Fewer race conditions en deadlocks.
- Standaardoptie: Gebruik synchroon tenzij asynchroon nodig is voor schaalbaarheid of betrouwbaarheid.
Wat zijn de voordelen en nadelen van asynchrone communicatie?
- Voordelen:
- Betere schaalbaarheid en prestaties.
- Minder risico op timeouts bij langzame services.
- Nadelen:
1. Complexiteit in data-synchronisatie.
2. Moeilijker te debuggen (race conditions, deadlocks).
Wat is de beste keuze voor een eenvoudig, budgetvriendelijk project?
Een modulaire monoliet:
* Eenvoudig te implementeren.
* Lage kosten.
* Geschikt voor kleine tot middelgrote applicaties.
Wat is een voorbeeld van een gedistribueerde architectuur?
Microservices-architectuur:
* Kenmerken: Gedecentraliseerde services, aparte databases, asynchrone communicatie.
* Geschikt voor: Schaalbare en complexe systemen.
* Voorbeeld: Het “Going, Going, Gone” project met services zoals BidCapture en VideoStreamer.
Wat is een quantum in architectuur?
Een quantum is een onafhankelijk deel van het systeem met unieke architectuureigenschappen. Het helpt bepalen:
1. Of een monolithische of gedistribueerde architectuur nodig is.
2. Hoe services, data, en communicatie gestructureerd moeten worden.
Wat zijn architecture decisions?
Keuzes die de structuur en technologie van een systeem beïnvloeden en ontwikkelteams begeleiden naar technische oplossingen.
Wat maakt een beslissing architectonisch significant?
Als het impact heeft op:
* Structuur
* Niet-functionele eigenschappen (bijv. schaalbaarheid, prestaties)
* Afhankelijkheden
* Interfaces
* Bouwtechnieken
Wat is een Architecture Decision Record (ADR)?
Een kort document (1-2 pagina’s) waarin een architectuurbeslissing, justificatie, gevolgen en alternatieven worden beschreven.
Wat zijn de voordelen van ADRs voor documentatie?
Ze bieden inzicht in waarom beslissingen zijn genomen.
2. Ze documenteren trade-offs en justificaties.
3. Ze voorkomen herhaalde discussies door duidelijke referentiepunten.
Wat is het doel van risicoanalyse in architectuur?
Het identificeren, beoordelen en mitigeren van risico’s zoals beschikbaarheid, schaalbaarheid en beveiliging om de veerkracht en het succes van een architectuur te verbeteren.
Wat zijn de twee dimensies van de Risicomatrix?
- Impact: Het effect van het risico als het zich voordoet (Laag = 1, Midden = 2, Hoog = 3).
- Waarschijnlijkheid: De kans dat het risico zich voordoet (Laag = 1, Midden = 2, Hoog = 3).
Wat is een risicoanalyse?
A: Een samenvattend rapport dat risico’s beoordeelt op basis van specifieke criteria en domeinen binnen een applicatie.
Wat is de rol van een risicobeoordeling?
Het identificeren en visualiseren van risico’s per criterium en domein, inclusief trends en prioriteiten voor verbetering.
Wat is Risk Storming?
Een collaboratieve oefening om risico’s binnen een architectuur te identificeren, consensus te bereiken en mitigerende acties te bepalen.
Wat zijn de drie fasen van Risk Storming?
- Identificatie: Individueel risico’s aanwijzen met behulp van een architectuurdiagram en risicomatrix.
- Consensus: Samenwerken om risico’s te bespreken en overeenstemming te bereiken.
- Mitigatie: Gezamenlijk oplossingen bedenken om risico’s te verminderen.
Hoe helpt Risk Storming bij architectuurverbetering?
Het onthult risico’s die anders onopgemerkt blijven en leidt tot gerichte wijzigingen, zoals betere beschikbaarheid, schaalbaarheid en beveiliging.
Waarom is Risk Storming een continu proces?
Risico’s veranderen door nieuwe functies, architectuurwijzigingen en incrementele ontwikkeling. Regelmatige sessies helpen risico’s vroegtijdig te detecteren.
Wat is het belang van samenwerking in Risk Storming?
Het brengt verschillende perspectieven samen, onthult onbekende risico’s en bevordert begrip tussen architecten en ontwikkelaars.
