Maak low-level design

Niet ieder onderdeel van de solution heeft nadere technische uitwerking nodig, en niet iedere use case wordt hier uitgewerkt. Deze activiteit richt zich alleen op de onderdelen met een architectuurbepalende eis, een aanzienlijk technisch risico, een complexe integratie of een belangrijke ontwerpbeslissing, en op de architectuurbepalende use cases die de werking van het ontwerp aantoonbaar maken: hoe de gekozen patronen werken en hoe de standaarden uit de paved road moeten worden toegepast. Zo'n use case wordt uitgewerkt tot een use-caserealisatie: een weergave waarin de bouwstenen uit de architectuurbeschrijving het scenario van de use case stap voor stap uitvoeren. Daarmee ontstaat de verbinding tussen de use-casespecificatie, die beschrijft wát er gebeurt, en de architectuurbeschrijving, die beschrijft waar het gebeurt. Voor de rest volstaat het detailniveau van het high-level design. Voor die geselecteerde onderdelen legt de architectuureigenaar, samen met ontwikkelaars, engineers, leveranciers en security- en dataspecialisten, vast hoe ze intern zijn opgebouwd, hoe ze samenwerken en hoe ze worden gerealiseerd — inclusief interfaces, gegevensverwerking en, waar relevant, de technische infrastructuur. De architectuurbepalende eisen zelf krijgen geen eigen werkproduct: ze worden hier in het low-level design verwerkt, en kunnen daarnaast in de architectuurrepository worden vastgelegd. Het resultaat is de directe basis voor implementatie, configuratie, bouw en technische toetsing.

Het low-level design bouwt voort op de containerindeling uit het high-level design. De containers worden hier niet opnieuw ontworpen, maar intern verder uitgewerkt; low-level design is immers een evolutie van dezelfde architectuurbeschrijving, geen apart document. Blijkt de containerstructuur onvoldoende aan te sluiten, dan wordt niet het high-level design aangepast, maar wordt de architectuurbeschrijving op dat punt verder ontwikkeld, voordat de detaillering verder gaat. Deze activiteit is daarmee iteratief: ze kan worden herhaald zodra architectuurbeslissingen uit andere activiteiten daar aanleiding toe geven. Per container wordt beschreven welke componenten worden onderscheiden, welke verantwoordelijkheden zij hebben en hoe zij communiceren, met de belangrijkste interfaces, gegevensuitwisselingen en technische afhankelijkheden. Verdere detaillering vindt alleen plaats waar dat nodig is om een architectuurbepalende eis te realiseren of te toetsen; voor de meeste componenten, en zeker voor standaardsoftware, blijft de implementatie de verantwoordelijkheid van het ontwikkelteam of de leverancier. Hetzelfde selectiecriterium geldt voor use cases: niet elke use case wordt uitgewerkt, alleen de architectuurbepalende use cases die laten zien hoe het ontwerp werkt, hoe de gekozen patronen functioneren en hoe de standaarden uit de paved road daarbij worden toegepast. Er is geen apart werkproduct voor de architectuurbepalende eisen zelf: ze worden verwerkt in dit low-level design, en kunnen daarnaast worden opgenomen in de architectuurrepository.

Beschrijven applicatielaag voor een use case

Een geselecteerde use case wordt uitgewerkt als dynamisch diagram (zie onderstaand voorbeeld): de bouwstenen uit de architectuurbeschrijving worden getoond met genummerde interacties die de volgorde aangeven waarin zij het scenario uitvoeren. Het diagram is geen nieuw model maar een extra weergave op dezelfde architectuurbeschrijving, zodat dezelfde containers en componenten worden gebruikt als in de statische diagrammen. De nummering volgt de genummerde stappen van het hoofdscenario in de use-casespecificatie; daardoor blijft de herkomst van elke interactie zichtbaar zonder dat er een apart koppelingsdocument nodig is. Het abstractieniveau is een keuze: op containerniveau wanneer de realisatie duidelijk moet maken hoe de bouwstenen samenwerken, op componentniveau alleen wanneer het risico juist binnen één container zit.

Terughoudendheid is hier het uitgangspunt. Een use-caserealisatie wordt gemaakt voor terugkerende samenwerkingspatronen en voor scenario's waarvan het samenspel tussen bouwstenen ingewikkeld genoeg is om misverstanden op te leveren — niet voor elke use case, en niet omdat de use case belangrijk is voor de gebruiker. Alternatieve scenario's krijgen geen eigen realisatie, tenzij het architectuurrisico zich juist daar bevindt: een niet-beschikbare koppeling of een mislukte transactie legt vaker een structurele tekortkoming bloot dan het gelukkige pad.

Beschrijven technologische laag

Waar relevant wordt naast de logische architectuur ook de technische infrastructuur beschreven: hoe containers worden uitgerold over servers, cloudomgevingen of netwerkzones, en of de topologie verschilt per omgeving. Een deploymentmodel wordt alleen opgenomen wanneer de infrastructuur zelf van invloed is op de architectuur, bijvoorbeeld door eisen aan beschikbaarheid, schaalbaarheid of netwerksegmentatie — gedetailleerde configuraties horen bij de implementatie, niet bij het ontwerp.

Bovenstaand voorbeeld toont een C4-deploymentdiagram: hoe de containers worden uitgerold over de productie-infrastructuur, inclusief netwerkzones, load balancing en de gebruikte voorzieningen.

Architectuurbeslissingen

Wijkt de uitwerking af van de geldende architectuurstandaarden of enterprise-richtlijnen, dan wordt dit expliciet vastgelegd als architectuurbeslissing, met de overwogen alternatieven en de motivatie voor de gekozen oplossing. Zodra de technische uitwerking van de eerstvolgende transitiestaat concreet genoeg is, wordt het migratiescenario voor die stap bijgewerkt tot operationeel niveau — systeemconfiguraties, datamappings, netwerkwijzigingen en testscripts; latere transitiestaten blijven bewust op het grovere detailniveau van het high-level design. De activiteit is afgerond zodra verantwoordelijkheden, interne structuur, gegevensverwerking, interfaces en technische randvoorwaarden voldoende eenduidig zijn vastgelegd om te realiseren, te configureren en te toetsen, zonder onnodige implementatiedetails of broncode voor te schrijven.