Wat is het C4 model?
Het C4 model gebruik ik om software-architectuur begrijpelijk te maken zonder direct te verdrinken in technische details.
Het model kijkt op vier niveaus naar een systeem:
Context: waar staat het systeem en met wie communiceert het?
Containers: uit welke applicaties, services, databases en andere onderdelen bestaat het?
Components: hoe is een specifieke service intern logisch opgebouwd?
Code: hoe ziet de implementatie er uiteindelijk uit?
Niet ieder systeem heeft alle vier de niveaus nodig. Voor mij zit de kracht van C4 juist in het bewust kiezen hoeveel detail op dat moment nodig is.
Waarom ik C4 gebruik
Architectuurdocumentatie moet vooral duidelijkheid geven.
Ik wil dat een developer, architect of stakeholder naar hetzelfde plaatje kan kijken en begrijpt waar we het over hebben. C4 helpt daar goed bij omdat je van buiten naar binnen werkt.
Ik gebruik het daarom vooral om:
systeemgrenzen duidelijk te maken
verantwoordelijkheden tussen services zichtbaar te maken
afhankelijkheden bespreekbaar te maken
architecturale keuzes uit te leggen
complexe distributed systems eenvoudiger over te brengen
Een architectuurdiagram is voor mij geen doel op zichzelf. Als een diagram meer uitleg nodig heeft dan het systeem zelf, dan is het waarschijnlijk te complex gemaakt.
Hoe ik ermee werk
Ik begin bijna altijd op Context of Container niveau.
Bij een microservice-architectuur wil ik bijvoorbeeld eerst zien welke services bestaan, welke verantwoordelijkheid ze hebben en hoe data tussen die services beweegt.
Pas wanneer een specifieke service meer uitleg nodig heeft, ga ik richting het Component-niveau.
Het Code-niveau gebruik ik beperkt. Uiteindelijk moet goede code voor een groot gedeelte zichzelf kunnen uitleggen.
Die manier van werken past ook bij hoe ik naar architectuur kijk: eerst het grote geheel begrijpen en daarna alleen verdieping toevoegen waar dat daadwerkelijk waarde heeft.
Waarom C4 voor mij ook een communicatiemiddel is
Recent ging ik op gesprek bij een bedrijf waarbij ik vooraf niet wist wie er precies aan tafel zouden zitten. Dat kon een developer zijn, maar net zo goed een architect, manager of iemand vanuit de business.
Juist daarom koos ik ervoor om mijn verhaal met het C4 model op te bouwen.
Ik kon beginnen bij de Context en het landschap eerst eenvoudig uitleggen. Als iemand technisch verder wilde gaan, kon ik daarna steeds een niveau dieper richting Containers en Components.
Dat vind ik een van de sterkste kanten van C4. Je hoeft vooraf niet precies te weten hoeveel technische kennis iemand heeft. Je begint gezamenlijk bij het grote geheel en bepaalt tijdens het gesprek hoeveel detail nodig is.
Voor mij is dat goede technische communicatie: eerst zorgen dat iedereen begrijpt waar we naar kijken, daarna pas de techniek induiken.
Belangrijk om te weten
C4 lost geen architectuurproblemen op.
Het maakt ze zichtbaar.
Een netjes getekend landschap kan nog steeds een slechte architectuur bevatten. Daarom gebruik ik C4 vooral als communicatiemiddel en niet als architectuurmethode die gevolgd moet worden omdat het nu eenmaal een standaard is.
Voor mij blijft de regel simpel: teken alleen wat helpt om het systeem beter te begrijpen.
Veelgestelde vragen die ik krijg over C4 model
Gebruik je altijd alle vier de niveaus?
Nee. Meestal zijn Context en Container voldoende. Ik voeg pas meer detail toe wanneer daar daadwerkelijk behoefte aan is.
Gebruik je C4 alleen voor microservices?
Nee. Juist bij een monolith kan C4 helpen om grenzen, verantwoordelijkheden en afhankelijkheden zichtbaar te maken.
Hoe gedetailleerd moet een C4 diagram zijn?
Zo gedetailleerd als nodig om een beslissing of gesprek te ondersteunen. Meer detail is niet automatisch betere documentatie.
Wanneer maak je een C4 diagram?
Vooral wanneer systemen complexer worden, meerdere teams betrokken zijn of architecturale keuzes duidelijk uitgelegd moeten worden.
Zie je C4 als documentatie of als ontwerptool?
Beide. Ik gebruik het om een architectuur vooraf te structureren, maar ook om bestaande systemen beter te begrijpen en keuzes later uitlegbaar te houden.