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.