Architectuur & Software design – hoe?

Bij trainingen en presentaties die ik geef over DDD, komt altijd de vraag op: maar hoe doe je dat ontwerpen nou precies, welk proces volg je daarvoor? Een logische vraag. En tevens één die lastig te beantwoorden is. Niet dat er helemaal geen antwoorden zijn hoor: er zijn vele ontwerpprocessen, methodologiën en checklists. Maar als je je daarin verdiept (heb er inmiddels redelijk wat van gelezen en toegepast), blijkt elke keer weer dat het met name ‘kapstokken’ zijn om je werkzaamheden aan te hangen. Wat ik daarmee bedoel: het zijn planningen met daarin fases en mogelijk zelfs specifieke sessies, inhoudelijk beschreven, liefst ook met het te verwachten eindresultaat. Maar wát je nou precies doet in zo’n sessie?

Zelf heb ik een aardig aantal van dit soort sessies mogen doen en we gebruiken daar ook een Sogyo domeinmodellerings-aanpak voor. Dit is typisch zo’n kapstok, waarin de belangrijke aspecten in staan waaraan gedacht moet worden: visiebepaling, domeinverkenning, gebruikersobservatie, processen doorlopen, technische randvoorwaarden bepalen, scope kiezen en een eventuele overdracht. Afhankelijk van de grootte van het project kan dit kleiner of groter gemaakt worden door meer of minder tijd voor bepaalde onderdelen te nemen, bepaalde aspecten samen te nemen of uit te gaan van reeds bestaande rapporten en documenten. Maar ook hier geldt weer dat er geen handleiding te vinden is voor het uitvoeren van de specifieke sessies.

Het wordt ook een heel werk om zo’n handleiding (hoe modelleer je?)  te schrijven en al helemaal om hem te gebruiken. De schrijver zou bijvoorbeeld kunnen kiezen voor het volledig uitschrijven van te maken keuzes, de mee te wegen factoren en de randvoorwaarden die moeten gelden, zodat het leesbaar wordt met minimale voorkennis. Maar dan wordt het wel onleesbaar dik en heel lastig toe te passen (wacht, dat moet ik even opzoeken op pagina 2350). En bovendien ook heel saai voor degene met al enige voorkennis. De schrijver zou ook kunnen kiezen voor een beschrijving op hoog niveau. Het nadeel dat je dan hebt is dat het voor een deel van de lezers het niet te volgen is. En voor de rest is de toegevoegde waarde waarschijnlijk niet zo groot.

Kortom, ik denk dat het niet zo eenvoudig formeel te beschrijven is. Het is een creatieve activiteit, die erg context gevoelig is. Het gaat dus om heel veel, context gevoelige kennis. Dat is veel beter over te dragen via training en samenwerken. Zodat degene die aan het leren is, op de momenten dat het nodig is, een vraag kan stellen die op dát moment relevant is en precies die instructies kan krijgen die in dát geval nuttig zijn. Essentieel is ook dat het in een reële casus toegepast wordt, want zonder doel en randvoorwaarden is ‘alles mogelijk’ en is er eigenlijk geen keuze te maken. Het beste systeem dat op dat moment denkbaar is, dat potentieel aan alle requirements kan voldoen, tegen zo min mogelijk kosten, is een nog-niet-ontworpen systeem.

Wat iemand die het wil leren, wél kan doen is in ieder geval de belangrijkste software design patterns leren (ja, gewoon uit het hoofd leren, zijn er echt niet zoveel, zo’n 51 in Patterns of Enterprise Appllication Architecture van Fowler en 65 in Enterprise Integration Patterns van Hophe en Woolf), verschillende architecturen kennen en weten waarom en hoe ze werken en wat de goede en zwakke kanten ervan zijn. Je ontkomt er toch niet aan om dit goed te kennen. En wat je verder nog kunt doen is goed leren samenvatten en luisteren. Wat zegt iemand en hoe zegt diegene dat? Als iemand je uitlegt hoe iets werkt of moet gaan werken en je hoort dingen die niet kloppen, dan moet je dat in ieder geval wel al gehoord hebben. Door dan samen te vatten wat de ander zegt, in jou eigen woorden, check je of datgene wat je begrepen hebt, ook daadwerkelijk klopt.

En er zijn natuurlijk ook wel specifieke boeken die ingaan op het ‘ontwerpen’ zelf, die zou je kunnen lezen, zoals bijvoorbeeld Streamlined Object Modeling van Nicola, Mayfield en Abney of Object Design: Roles, Responsibilities, and Collaborations van Rebecca Wirfs-Brock. Deze helpen je denk ik wel verder, maar het meeste leer je toch van het samen ontwerpen met iemand die er goed in is. En je kunt herkennen of iemand er goed in is, als diegene goede ontwerpen oplevert die werken en gedurende het ontwerpen zelf duidelijk laat zien een patroon/probleem te herkennen en gestructureerd tot een oplossing te kunnen komen.

Het is wel belangrijk om het ontwerpen goed onder de knie te hebben, denk ik. Sterker nog, het lijkt er steeds meer op dat dit dé belangrijkste activiteit van software ontwikkeling is. In een model-driven ontwikkelomgeving is dit de enige activiteit die overblijft.

Hoe doe jij dit en hoe heb jij dit geleerd? Of hoe ben je van plan dit aan te gaan pakken? Herken je iets van de bovenstaande observaties en stellingen uit je eigen praktijk?