Software-architecture design: de beste tips en best practices

Je zou niet aan een project willen beginnen zonder een goed plan, en bij het ontwerpen van software-architectuur is dat niet anders. Door dit proces doeltreffender te maken, kun je goed rekening houden met al je vereisten en stakeholders de kans geven om input te geven.

Met behulp van technische visuals en een zorgvuldig planningsproces kun je de software-architectuur en het ontwerp schetsen voordat je aan een prototype begint. 

Wat is software-architecture design? 

Bij het ontwerpen van software-architectuur wordt programmeerkennis gebruikt om het algemene ontwerp van software te plannen, zodat er later details aan kunnen worden toegevoegd. Zo kunnen softwareteams het grote geheel schetsen en beginnen met de voorbereiding van een prototype. 

Door de tips en best practices voor het ontwerpen van software-architectuur te volgen, kunnen softwareontwikkelaars nadenken over de kenmerken van hun software en bepalen hoe de software-architectuur moet worden ontworpen. 

Software design in 5 stappen

1. Heb een duidelijk inzicht in je vereisten

Elk software ontwerp waaraan je begint, heeft zowel functionele als niet-functionele vereisten. Deze vereisten sturen je software-architectuur en stellen je in staat het project af te ronden met een eindproduct waar je stakeholders tevreden mee zijn.

Zonder een duidelijk inzicht in deze vereisten loopt je team het risico de weg kwijt te raken, de verkeerde vereisten te belichten ten koste van andere, of een inefficiënte hoeveelheid interne middelen te gebruiken. 

Krijg een beter inzicht dankzij visuals — volg deze stappen om je vereisten in kaart te brengen met een intelligent diagramplatform zoals Lucidchart:

• Begin met een algemeen overzicht: schets eerst je vereisten in een 'helicopterview'. Mindmapping is een doeltreffende manier om dit te doen. 

• Breng je functionele vereisten in kaart: je kunt werkwoorden gebruiken om je te helpen om zelfstandige naamwoorden samen te groeperen. Werkwoorden als 'bekijken' en 'bewerken' kunnen bijvoorbeeld de woorden 'account' of 'profiel' aan elkaar linken in een mindmap van functionele gebieden. 

• Houd rekening met niet-functionele vereisten: terwijl je aan je mindmap werkt, kun je je niet-functionele vereisten noteren voor later. Een vereiste zoals 'prestaties' is belangrijk maar is waarschijnlijk te abstract om op de mindmap te plaatsen. 

Aan de hand van je vereisten moet je de omvang van je werk bepalen en je project plannen.

2. Begin na te denken over elk onderdeel

Laten we eerlijk zijn: gezien de grote invloed die je functionele vereisten hebben op je project, kan het zijn dat je ontwerp- en technologische keuzes al vaststaan zodra je je vereisten in kaart hebt gebracht. 

Zonder op de zaken vooruit te lopen wat de implementatie betreft, moet je nagaan welke vereisten een belangrijke uitdaging vormen voor je ontwerp of je projectplan. Sommige vereisten kunnen onmogelijk zijn volgens bepaalde veronderstellingen of keuzes. 

• Begin met een 'perfecte wereld': hoe zou je ontwerp eruitzien als je dit helemaal perfect kon maken? 

• Overweeg en documenteer de implicaties van je vereisten: maak een werkconcept met je team en ontwikkel het geleidelijk. Eerst wil je kijken naar wat je vereisten betekenen voor je ontwerp, bijvoorbeeld welke individuele items van je verlanglijstje voor stakeholders elkaar kunnen tegenspreken of kunnen botsen met andere functionele en niet-functionele vereisten. 

• Wacht en ontwerp later de definitieve architectuur: je architectuurplanning zal hoogstwaarschijnlijk gedurende dit proces veranderen, dus verwacht niet dat het eerste ontwerp zal lijken op het eindresultaat. 

3. Verdeel je software-architectuur in stukken

Je architectuurontwerp gaat vanzelf over in een planningsfase als je gaat beslissen hoe je je ontwerp gaat uitvoeren. Door je architectuur onder te verdelen, kun je dit plan zo ontwerpen dat het waarde oplevert voor de gebruikers en dat je het gebruik van middelen goed plant. 

Het is nuttig om te denken dat je een taart snijdt. De meeste mensen snijden een taart verticaal, door elke laag heen. Laten we zeggen dat een volledig stuk een glazuurlaag, vulling, en twee of drie lagen biscuit bevat. Dat verticale stukje heeft een beetje van alles. Taarten kunnen ook horizontaal worden gesneden, waardoor de verschillende lagen van elkaar worden gescheiden. 

Als elk stukje een verhaal voorstelt dat wordt gebruikt om je software-architectuur te plannen, dan zijn er ook lagen: als je de taart verticaal in punten snijdt, creëer je verhalen die gericht zijn op individuele functies, terwijl je bij horizontaal snijden individuele componenten onthult. Je hebt zowel het horizontale als het verticale denkvermogen nodig voor je project. 

Agile richt zich op verticaal gesneden taartpunten, waardoor je team al snel een meerwaarde kan bieden. Deze aanpak zorgt ervoor dat klanten snel op de hoogte zijn van de productvoortgang en dat het ontwikkelingsteam feedback krijgt over elke laag achter een functie. Een taartpunt van je software-architectuur voor een e-commercesite kan het afrekenproces zijn. 

In het stukje 'afrekenen' zie je de gegevenslaag die de betalingsinformatie opslaat, de middelste laag API, en als bovenste laag de gebruikersinterface die de klanten te zien krijgen. Met verticale taartpunten kun je beslissen welke functies je wilt aanbieden en iteratieve stukken kiezen.

Door de lagen te schetsen die een rol spelen in je software-architectuurproject, kun je het geheel visualiseren en zien hoe elke laag de andere lagen beïnvloedt. Neem tijdens het plannen individuele stukken van de agile-taart en schets hoe ze op elkaar aansluiten.

4. Prototyping tijdens softwareontwikkeling

Maak altijd een prototype. Prototypes zorgen ervoor dat je snel en vroeg fouten kunt maken; zo krijg je snel feedback en kun je je proof-of-concept ontdekken. Dit is een belangrijk onderdeel om je werk te valideren en je veronderstellingen te controleren om er zeker van te zijn dat ze juist en grondig zijn. 

Onthoud bij het maken van je prototype dat de eerste paar iteraties nooit perfect zullen zijn en dat ook geen enkele laatste iteratie helemaal perfect zal zijn. Een van de voordelen van prototypes is dat ze niet als afgewerkt product dienen. De meeste mensen verwachten instinctief dat een prototype op zijn minst wat ruwe kantjes heeft. 

Maak gebruik van de prototypefase. Dit is geen vervanging voor testen, maar het is een cruciaal onderdeel van het testen dat moet gebeuren. 

• Houd een zorgvuldige revisiegeschiedenis bij: als je niet bijhoudt wat je leert van prototypes, loop je natuurlijk het risico dat je je fouten herhaalt. Schrijf alles op: documenteer je ontwerpbeslissingen en de veranderingen die je gaandeweg aanbrengt.

• Gebruik één enkele bron van waarheid: je wilt niet dat meerdere wijzigingen en verschillende versies je voortgang in de weg staan, dus zorg voor een degelijk versiebeheer dat gericht is op één enkele bron voor je documentatie. 

• Maak een diagram van je prototypes: je kunt diagrammen gebruiken om je te helpen om wijzigingen van je protoype te beheren en de verschillen tussen elke versie te visualiseren. 

5. Identificeer en kwantificeer niet-functionele vereisten

Naast de functionele vereisten, moet je ook rekening houden met de niet-functionele vereisten. Deze vereisten zijn even belangrijk voor het ontwerp als je functionele vereisten, omdat ze de kenmerken van het systeem bepalen. 

Niet-functionele vereisten zijn vaak hoogwaardige kwaliteitseisen voor het gehele project, maar niet altijd. Het is mogelijk dat je systeem niet-functionele vereisten heeft die specifiek zijn voor slechts een deel van je software-architectuur. Daarom moet je bereid zijn om stakeholders in te schakelen voor lokale niet-functionele vereisten. Zo kan een bepaald verticaal stuk van het project vooral het klantenserviceteam interesseren, en dat team kan zijn eigen verwachtingen hebben over die niet-functionele vereisten.

Het is echter niet genoeg om te zeggen dat je prestaties, portabiliteit of schaalbaarheid wilt. Niet-functionele vereisten moeten ook worden gekwantificeerd. Geen enkel project kan altijd perfecte prestaties leveren: 'prestaties' moeten worden gespecificeerd en beperkt om aan andere vereisten te voldoen. 

Omdat je niet-functionele vereisten een rol spelen in het vormgeven van je ontwerp, kun je er niet omheen om ze te definiëren. Hier zijn enkele andere vereisten die je zou kunnen overwegen:

• Prestaties: hoe goed je hele systeem presteert, maar ook de afzonderlijke stukken of lagen

• Schaalbaarheid: huidige en toekomstige mogelijkheden om je systeem aan te passen aan je behoeften

• Portabiliteit: je gegevensportabiliteit en de mogelijke portabiliteit van onderdelen van je systeem, indien van toepassing of noodzakelijk

• Uitbreidbaarheid: met het oog op de toekomstige groei van je systeem en je bedrijf, hoe goed je systeem zich kan aanpassen en de moeite die het kost om het aan te passen

• Naleving: een andere essentiële factor die een aanzienlijke invloed heeft op je hele projectontwerp

Het in kaart brengen van je niet-functionele vereisten kan je team helpen om te begrijpen hoe je ze kwantificeert terwijl je ook specifieke vereisten in relevante contexten plaatst. Hoewel je je nog geen zorgen hoeft te maken over de optimalisatie, moet je ook nagaan welke inspanning en middelen nodig zouden kunnen zijn om deze niet-functionele vereisten later te optimaliseren. 

Best practices voor software-architecture design

Wanneer je aan je ontwerpproject begint, zullen deze best practices je helpen om goede ontwerpprincipes te blijven aanhouden. 

Visualiseer je ontwerp 

Door gebruik te maken van visuals in zowel je ontwerpconcept als je implementatie, kan je team het algemene perspectief van je ontwerp zien. Diagrammen zijn een geweldige manier om processen en verschillende aspecten van je ontwerpkeuzes te visualiseren.

Kies geen patronen 

Richt je ontwerpproces op het grotere geheel zonder gebruik te maken van patronen als uitgangspunt. In plaats van patronen te gebruiken, moet je op een zeer hoog niveau blijven met een overzicht van algemene onderdelen om het risico van overengineering van je systemen te verminderen. 

Vergeet niet dat het eerste ontwerp slechts de eerste iteratie is 

Dankzij je eerste ontwerp krijg je een beter beeld van de technische uitdagingen en obstakels waarmee je bij de ontwikkeling van je architectuur te maken krijgt. Verwacht niet dat het eerste ontwerp meer is dan een prototype! 

Maak je geen zorgen, je architectuurontwerp zal groeien en zich ontwikkelen, zodat je na verloop van tijd meer van de details kunt uitzoeken. 

Wees voorzichtig met een scope creep 

Ook al lijkt het aanlokkelijk om je scope uit te breiden, gaat scope creep ten koste van je andere vereisten en kan het de nodige middelen opslokken. Om scope creep te stoppen, stel je een projectplan met werkconcept op dat rekening houdt met je vereisten. Voer een gesprek met stakeholders over de grenzen van de niet-functionele vereisten. Je wilt niet dat onvervulde verwachtingen je project negatief beïnvloeden. 

Houd grenzen en interfaces in gedachten

Denk bij het plannen van je ontwerp na over interfaces tussen onderdelen en let op de grenzen van je systeem. Begin met het toewijzen van verantwoordelijkheden, zodat je deze informatie bij het werken aan je prototypes en volgende iteraties gemakkelijk bij de hand hebt.

Verbeter nu het ontwerp van je software-architectuur

Het ontwerpen van software-architectuur is effectiever als er een plan is, input van stakeholders, en de juiste aanpak voor het schetsen van de projectvereisten. Bespaar niet op deze eerste planning, en je inspanningen kunnen worden beloond met een vlotter verloop van het project.