Software Architecture Flashcards

1
Q

Software-architectuur

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Component

A

Een zelfstandig functioneel onderdeel van een softwaretoepassing, zoals een module, service of microservice. Componenten hebben duidelijke verantwoordelijkheden en communiceren via goed gedefinieerde interfaces.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Interface

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Layered Architecture

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Microservices

A

Een architectuurstijl waarbij een applicatie wordt opgebouwd uit kleine, zelfstandige services die onafhankelijk kunnen worden ontwikkeld, ingezet en geschaald.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Design Patterns

A

Herbruikbare oplossingen voor veelvoorkomende ontwerpproblemen in softwareontwikkeling. Voorbeelden zijn het Singleton-, Factory-, en Observer-patroon.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Service-Oriented Architecture (SOA)

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Scalability

A

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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Coupling en Cohesion

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Architectural Styles

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Domain-Driven Design (DDD)

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Non-Functionele Eisen (NFRs)

A

Kwaliteitseisen van een systeem, zoals performance, beveiliging, betrouwbaarheid en schaalbaarheid. Ze beïnvloeden de keuzes in de architectuur sterk.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Deployment Architecture

A

De configuratie van softwarecomponenten op hardware en infrastructuur. Het bepaalt hoe een systeem wordt geïmplementeerd en uitgevoerd in productieomgevingen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Monolith

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Distributed Systems

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Technische opdeling

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Opdeling in Domeinen

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Synchrone communicatie

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Asynchrone communicatie

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Wat zijn de acht belangrijkste verwachtingen van een software architect?

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Wat is een uitdaging bij het definiëren van software architectuur?

A

Het verandert continu door technologische vooruitgang, zoals microservices en DevOps.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Welke elementen omvat software architectuur?

A

Structuur, architectuurkarakteristieken (”-ilities”), architectuurbeslissingen, en designprincipes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Waarom is alleen het benoemen van een architectuurstijl (zoals microservices) niet voldoende?

A

Omdat ook de onderliggende beslissingen en eigenschappen belangrijk zijn.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Wat is de belangrijkste taak van een software architect bij architectuurbeslissingen?

A

Het vaststellen van richtlijnen en regels voor hoe technologie wordt gebruikt.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Wat is “architectural decay”?

A

Het proces waarbij een architectuur minder efficiënt wordt door veranderingen in technologie en bedrijfsbehoeften.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Waarom is kennis van het bedrijfsdomein belangrijk voor een software architect?

A

Het helpt bij het begrijpen en ontwerpen van oplossingen die aansluiten bij zakelijke eisen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Wat zijn de twee wetten van software architectuur?

A

1) Alles in softwarearchitectuur is een trade-off.
2) Waarom is belangrijker dan hoe.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Wat zijn fitness functions in evolutionaire architecturen?

A

Mechanismen, zoals tests of monitoring, om ervoor te zorgen dat belangrijke architectuurkenmerken intact blijven.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Wat is een cruciale vaardigheid van een software architect?

A

Het omgaan met politiek binnen de organisatie en het navigeren van weerstand tegen veranderingen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Welke impact heeft DevOps op software architectuur?

A

Het bevordert samenwerking tussen ontwikkelaars en operations, waardoor schaalbaarheid en betrouwbaarheid verbeteren.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Wat is architecturaal denken?

A

Het bekijken van softwareprojecten vanuit een architectonisch perspectief, met focus op structurele, technische en zakelijke aspecten.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Wat zijn de vier belangrijke aspecten van architecturaal denken?

A

1) Verschil tussen architectuur en design,
2) Technische breedte vs. diepte,
3) Trade-offs analyseren,
4) Begrijpen van zakelijke drijfveren.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Wat is het verschil tussen architectuur en design?

A

Architectuur gaat over structurele beslissingen en “-ilities,” terwijl design focust op de implementatie van componenten.

34
Q

Wat is de kennispiramide voor een architect?

A

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).

35
Q

Wat is het “Frozen Caveman Anti-Pattern”?

A

Wanneer een architect vasthoudt aan verouderde ideeën door negatieve ervaringen uit het verleden.

36
Q

Hoe moeten architecten omgaan met nieuwe technologieën?

A

Nieuwe technologieën blijven verkennen en objectief naar oplossingen kijken.

37
Q

Wat zijn tips om als architect hands-on te blijven?

A

POC’s maken, technische schulden oplossen, bugfixes doen, automatiseringstools ontwikkelen, en code reviews uitvoeren.

38
Q

Wat is de belangrijkste rol van een architect in samenwerking met ontwikkelaars?

A

Mentoren, coachen en bidirectioneel communiceren om architectuurprincipes goed te implementeren.

39
Q

Wat betekent architecturaal denken in de praktijk?

A

Brede technische kennis hebben, samenwerken met teams, trade-offs analyseren, en oplossingen kiezen op basis van zakelijke en technische behoeften.

40
Q

Wat is modulariteit in software?

A

Het logisch groeperen van gerelateerde code in modules om complexiteit te verminderen en onderhoud te vergemakkelijken.

41
Q

Wat zijn de drie metrieken om modulariteit te meten?

A

Cohesie, koppeling en connascence.

42
Q

Wat is cohesie in modulariteit?

A

De mate waarin onderdelen van een module logisch met elkaar verbonden zijn.

43
Q

Wat is koppeling in modulariteit?

A

De mate waarin modules afhankelijk zijn van elkaar.

44
Q

Wat is connascence?

A

Een verfijnde kijk op koppeling, waarbij modules samen moeten veranderen om de correctheid van het systeem te behouden.

45
Q

Wat is het verschil tussen modules en componenten?

A

Modules zijn logische groeperingen van code, terwijl componenten fysieke implementaties zijn die kunnen worden hergebruikt.

46
Q

Wat zijn de voordelen van modulariteit in software?

A

Schaalbaarheid, onderhoudbaarheid en begrijpelijkheid van systemen verbeteren.

47
Q

Waarom is modulariteit essentieel voor softwarearchitectuur?

A

Het maakt complexe systemen beter beheersbaar en aanpasbaar aan verandering.

48
Q

Wat zijn architectuurkenmerken?

A

Belangrijke ontwerpcriteria die beschrijven hoe een systeem moet presteren en waarom bepaalde ontwerpkeuzes zijn gemaakt.

49
Q

Aan welke drie criteria moet een architectuurkenmerk voldoen?

A

1) Niet-domeinspecifiek,
2) Beïnvloedt een structureel aspect van het ontwerp,
3) Cruciaal voor het succes van de applicatie.

50
Q

Noem drie voorbeelden van operationele architectuurkenmerken.

A

Beschikbaarheid, prestaties, schaalbaarheid.

51
Q

Noem drie voorbeelden van structurele architectuurkenmerken.

A

Uitbreidbaarheid, onderhoudbaarheid, portabiliteit.

52
Q

Noem drie voorbeelden van cross-cutting architectuurkenmerken.

A

Beveiliging, toegankelijkheid, privacy.

53
Q

Wat beschrijven ISO-standaarden voor architectuurkenmerken?

A

Definities voor kenmerken zoals prestaties, compatibiliteit, gebruiksvriendelijkheid, beveiliging, en onderhoudbaarheid.

54
Q

Wat is een veelvoorkomende trade-off bij architectuurkenmerken?

A

Het verbeteren van beveiliging kan een negatief effect hebben op prestaties.

55
Q

Waarom streven architecten naar de “minst slechte architectuur”?

A

Omdat een perfecte architectuur onhaalbaar is en er altijd trade-offs zijn tussen kenmerken.

56
Q

Wat is het doel van iteratief ontwerpen in softwarearchitectuur?

A

Aanpassingen aan de architectuur vergemakkelijken en flexibiliteit behouden.

57
Q

Wat zijn architectuurkenmerken?

A

Belangrijke ontwerpcriteria zoals schaalbaarheid, prestaties en veiligheid, die de basis vormen voor architectonische keuzes.

58
Q

Wat zijn de drie manieren om architectuurkenmerken te identificeren?

A

1) Extractie uit domeinproblemen,
2) Extractie uit vereisten,
3) Gebruik van impliciete domeinkennis.

59
Q

Hoe vertalen architecten domeinproblemen naar architectuurkenmerken?

A

Door zakelijke termen zoals “gebruikerssatisfactie” te koppelen aan technische termen zoals prestaties of beschikbaarheid.

60
Q

Wat is het verschil tussen schaalbaarheid en elasticiteit?

A

Schaalbaarheid: Meer gebruikers kunnen ondersteunen zonder prestatieverlies.

Elasticiteit: Snel reageren op pieken in verkeer.

61
Q

Wat is het verschil tussen een designbeslissing en een architectuurbeslissing?

A

Designbeslissing: Specifieke implementatiedetails zoals een design pattern.

Architectuurbeslissing: Structurele keuzes zoals een microkernel-architectuur.

62
Q

Wat is een belangrijk doel bij het identificeren van architectuurkenmerken?

A

Een balans vinden tussen prestaties, schaalbaarheid, veiligheid en flexibiliteit.

63
Q

Wat zijn fitness functions in softwarearchitectuur?

A

Automatische checks die ervoor zorgen dat architectuurkenmerken worden nageleefd.

64
Q

Noem drie voorbeelden van fitness functions.

A

1) Cyclische afhankelijkheden checken,
2) Layered architecture controleren,
3) Chaos engineering tests.

65
Q

Waarom zijn fitness functions belangrijk?

A

Ze automatiseren governance, voorkomen handmatig toezicht en garanderen een balans tussen snelheid en kwaliteit.

66
Q

Wat is connascence in softwarearchitectuur?

A

Het concept dat twee componenten gekoppeld zijn, zodat een wijziging in de ene een aanpassing in de andere vereist.

67
Q

Wat zijn de twee soorten connascence?

A

1) Statisch: Gedefinieerd door code-analyse, zoals gedeelde klassen.

2) Dynamisch: Ontstaat tijdens runtime, bijvoorbeeld via synchronisatie.

68
Q

Wat is het verschil tussen libraries en services als componenten?

A

Libraries draaien in hetzelfde geheugen en zijn compile-time afhankelijkheden, terwijl services losstaan en communiceren via protocollen zoals REST.

69
Q

Wat zijn de twee stijlen van architecture partitioning?

A

1) Layered Monolith (technische lagen),
2) Modular Monolith (domeinen of workflows).

70
Q

Wat is een voordeel van een gedistribueerde architectuur?

A

Geschikt voor systemen met verschillende architectuurkenmerken zoals schaalbaarheid en elasticiteit.

71
Q

Wanneer zou je kiezen voor een monolithische architectuur?

A

Als het systeem uniforme architectuurkenmerken heeft en uit één quantum bestaat.

72
Q

Wat is de impact van componenten op modulariteit?

A

Componenten maken systemen opdeelbaar in begrijpelijke, zelfstandig inzetbare eenheden, wat modulariteit vergroot.

73
Q

Wat is een belangrijke conclusie over component-gebaseerd denken?

A

Architecten moeten continu itereren en een balans vinden tussen granulariteit, afhankelijkheden en architectuurkenmerken.

74
Q

Wat beschrijven architectuurstijlen en -patronen?

A

Gestructureerde relaties tussen componenten binnen een systeem, zoals Layered Architecture of Microservices.

75
Q

Wat is het anti-pattern Big Ball of Mud?

A

Een ongeorganiseerd, chaotisch systeem zonder duidelijke structuur, wat leidt tot slechte aanpasbaarheid en prestaties.

76
Q

Wat is een Client/Server Architecture?

A

Een twee-lagen architectuur waarbij een client (frontend) communiceert met een server (backend), zoals een webbrowser en een webserver.

77
Q

Wat zijn de drie lagen in een Three-Tier Architecture?

A

Frontend, applicatielaag, en databank.

78
Q

Wat is het verschil tussen monolithische en gedistribueerde architecturen?

A

Monolithische architecturen hebben één deploymenteenheid, terwijl gedistribueerde architecturen bestaan uit meerdere onafhankelijke deploymentunits.

79
Q

Noem een voordeel en een nadeel van een gedistribueerde architectuur.

A

Voordeel: Hogere schaalbaarheid en prestaties.
Nadeel: Complex beheer en latentieproblemen.

80
Q

Wat zijn uitdagingen bij gedistribueerde architecturen?

A

Distributed logging, distributed transactions, en contract maintenance/versioning.

81
Q

Wat is de belangrijkste focus bij het leren van gedistribueerde architecturen?

A

Begrijp de fundamentele patronen, de fallacies of distributed computing, en uitdagingen zoals logging en transacties.