Architectuur & Software design – hoe?

 
09 januari 2011

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?


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Project- & procesmanagement, Architectuur, Development, Professionele vaardigheden

Tags: , , , , , , ,


Reacties (4)

  • Evolutionair lijkt me inderdaad ook het beste, aangezien je altijd nog veel leert over een project, door veranderingen/verhelderingen in de requirements en door het implementeren zelf.

    Het is in ieder geval belangrlijk dat een team de gebruikte patterns en frameworks goed kent. En liefst ook enige hulp krijgt bij de goede toepassing ervan.

    Overigens vind ik dit nog redelijk losstaan van het (domein-)modelleren. De architectuur heeft met name verbanden met de non-functionele requirements, is mijn ervaring.

    Geplaatst op 23 januari 2011 om 18:14 Permalink

  • Persoonlijk ben ik een groot voorstander van een evolutionaire aanpak. Dit maakt echter niet overbodig om een ‘componentenontwerp’ aan het begin van je project neer te zetten en deze ook te bewaken. Mijn ervaring is dat als de requirements voldoende in kaart zijn je zo’n kader prima kunt neerzetten.
    De verdere modellering geschiedt naarmate het project vordert. Dit is ook één van de uitgangspunten die je moet hanteren bij je initiële ontwerp: groei op verschillende vlakken moet gemakkelijk mogelijk zijn.
    Om de kleurplaat die je hebt getekend dan in te kleuren kunnen teams gebruik maken van design patterns en eventueel frameworks. De laatste uiteraard met mate en slechts goed onderbouwd.

    Geplaatst op 21 januari 2011 om 14:17 Permalink

  • Goeie boeken.

    Tip: plaats eens een samenvatting als je er 1 gelezen hebt.

    Geplaatst op 10 januari 2011 om 11:29 Permalink

  • Code Complete 2 (McConnel), Domain Driven Design (Evans) en Object Design: Roles, Responsibilities, and Collaborations staan op mijn lijstje om te lezen :)

    Geplaatst op 10 januari 2011 om 11:06 Permalink