Software Architecture

Question 1

Software-architectuur

Answer 1

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.

Question 2

Component

Answer 2

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

Question 3

Interface

Answer 3

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.

Question 4

Layered Architecture

Answer 4

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.

Question 5

Microservices

Answer 5

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

Question 6

Design Patterns

Answer 6

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

Question 7

Service-Oriented Architecture (SOA)

Answer 7

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.

Question 8

Scalability

Answer 8

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

Question 9

Coupling en Cohesion

Answer 9

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.

Question 10

Architectural Styles

Answer 10

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.

Question 11

Domain-Driven Design (DDD)

Answer 11

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.

Question 12

Non-Functionele Eisen (NFRs)

Answer 12

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

Question 13

Deployment Architecture

Answer 13

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

Question 14

Monolith

Answer 14

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.

Question 15

Distributed Systems

Answer 15

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.

Question 16

Technische opdeling

Answer 16

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.

Question 17

Opdeling in Domeinen

Answer 17

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.

Question 18

Synchrone communicatie

Answer 18

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.

Question 19

Asynchrone communicatie

Answer 19

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.