Business-To-Code

 
30 mei 2008

Software engineering is een vakgebied dat zich in mijn optiek hoofdzakelijk bezighoudt met het vertalen van businessvragen naar executeerbare code. Met businessvragen bedoel ik in deze context een bepaalde set aan problemen of functionaliteiten die – in natuurlijke taal gedefinieerd – tezamen een automatiseringsvraag representeren van een organisatie.
Droog gezegd zijn we dus vaak gesproken of geschreven teksten aan het vertalen naar strings van enen en nullen. Deze laatste strings zijn handig aangezien we ze kunnen voeden aan een machine die ze kan executeren om zo een geautomatiseerde oplossing te bieden aan de eerder beschreven businessvragen.

Aangezien het direct invoeren van strings van enen en nullen een nogal foutgevoelig en bijzonder tijdrovend werk bleek te zijn we over de jaren heen een aantal abstractieniveau’s hoger gaan werken. Als eerste abstractie van deze code waren daar de assemblytalen, ook wel 2GL talen genoemd. Hoewel dit een grote stap voorwaarts was bleken dit toch niet de meest optimale talen te zijn voor software engineering aan de technische kant. Al vrij snel werd duidelijk dat een redelijke mix van abstractieniveau en flexibiliteit behaald werd met de zgn. 3GL talen als C, Pascal, Cobol. Zonder nu verder heel diep in te gaan op deze evolutie in programmeertalen kunnen we stellen dat we voor algemene IT vraagstukken vandaag de dag ongeveer op dit niveau zijn blijven hangen. Ik ga niet in op 4GL of 5GL aangezien hiermee in mijn optiek geen generieke businessvragen oplost kunnen worden.

Uiteraard zijn er waardevolle concepten toegevoegd aan deze 3GL talen. Ik wil hier op de belangrijkste ingaan en dat is in mijn optiek het principe van object orientatie. Als techneuten hebben we de meerwaarde van dit concept inmiddels bijna allemaal omarmd, en we zijn er zelfs zover in gegaan dat sommigen beweren dat dit concept goed gebruikt kan worden om de resterende vertaalslag van businessvragen tot 3GL code te maken.
Onder de noemer ‘domain driven design’ worden klantvragen min of meer direct vertaald naar ‘domain models’ en een kenmerk van deze domain models is dat ze vrijwel direct mappen op objectgeorienteerde 3GL talen als Java, C# of Smalltalk. In feite ben je samen met de klant aan het programmeren en ik kan in deze gedachtengang een eind meegaan.

Ik ben echter van mening dat er twee wrijvingspunten zijn in deze techniek, en graag zou ik daar met de lezers die hier helemaal gekomen zijn van gedachten wisselen over deze twee punten. Hieronder heb ik het plaatje getekend met uiteraard de software engineer als stralend middelpunt en de klant bovenin met een of andere vraag die hij in zijn eigen taal kan beantwoorden.
Deze vraag kan de klant heel goed omschrijven in wat ik noem een ‘Customer Specific Model’. Dit model kan niet in een bepaalde taal gevat worden aangezien deze voor elke klant ook weer specifiek is. Dit klantspecifieke model kan je vertalen naar wat de DDD’ers een ‘Domain Model’ noemen maar om dit goed in sync te houden is in mijn optiek het eerste vlak waar het moeilijk wordt. Een eerste punt van discussie dat ik zou willen poneren is dan ook: is een Domain Model het juiste gereedschap om met de klant te praten? En hoe verifieer ik het model bij de klant?

Een tweede punt waar in mijn optiek vaak te snel overheen gestapt wordt is het vertalen van dit domeinmodel naar een ‘echt’ objectmodel. Ik heb het dan nog niet over de stap van executeerbare businesscode naar applicatie: deze stap is al wel heel veel over gezegd en geschreven (het koppelen van componenten, aansluiten van UI laag en datalaag) dus dat zal ik hier verder achterwege laten. Nee, wat ik bedoel is het toepassen van geschikte patterns en practices binnen het businessmodel. Een domain model bevat in mijn optiek nooit ingewikkelde gedragspatterns als ‘strategy’ of ‘state’. Immers, een businessvraag kan heel goed deels opgelost worden door toepassing van een van deze patterns maar patterns maken nooit deel uit van de conceptuele kern van het probleem. Ik heb hieronder Domain Model en Object Model dus ook gescheiden. Het laatste stukje, van OO model naar executeerbare software (enen en nullen) heb ik in 1 stadium gezet:
Ik zou graag met de geinteresseerde lezer die hier op- of aanvullingen op heeft van gedachten wisselen over deze verschillende abstractieniveau’s. Met name ben ik geintersseerd in ervaringen en technieken met de vertaalslag van klantspecifieke modellen of omschrijvingen naar domeinmodellen. Een evenzo interessante vind ik de patterns en practices die benodigd zijn voor de vertaling van domain model naar een rijk objectmodel.


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


Categorieën: Architectuur, Development

Tags: , ,


Reacties (3)

  • Ivo Limmen schreef:

    @Johan: Ik was bij de Exploratory Modelling in de praktijk sessie met Rob Vens op de J-Spring. Rob ging hierin samen met het publiek een modellering sessie houden. Dat was erg leuk maar vereist dat het publiek OO modelering toch een beetje begreep. Tech-savyness is hierbij dan toch wel weer handig.
    Ik ben het zeer zeker met je eens dat het ook zijn nadelen heeft: ik heb ook wel eens een klant gehad die per se AJAX wilde in zijn applicatie. Maar hij had er geen geldende reden voor.

    Geplaatst op 31 mei 2008 om 22:51 Permalink

  • Volgens mij heeft tech-savy niet zoveel te maken met het opstellen van een domain model.
    Je wilt zelfs eigenlijk niet dat iemand dan al met de technische implementatie bezig is, je wilt alleen in kaart brengen hoe iets zou moeten werken (of bij automatisering hoe iets nu werkt, en welk gedeelte geautomatiseerd moet worden). Een hoog abstractie-niveau en ervaring met modelleren kan wel erg nuttig zijn (en dat hangt wel deels samen met tech-savy).

    Het splitsen van een domain model en het optimized model is wel handig, maar het moet wel zo min mogelijk extra beperkingen opleggen aan het domain model.

    Wat ik tot nu toe meemaak is dat er iets nieuws gemaakt wordt, waardoor het customer specific model zelfs aan verandering onderhevig is. Daardoor wordt het optimized model redelijk gelijk gehouden aan het domain model.

    Geplaatst op 30 mei 2008 om 10:02 Permalink

  • Ivo Limmen schreef:

    Je eerste vraag is volgens mij niet zo een groot probleem. Steeds meer mensen in deze wereld worden tech-savy. Men groeit op met computers en ze begrijpen er steeds meer van. Ik denk dat de aanpak van Rob Vens daarom ook prima werkt.
    Ik ben het met je eens: er zit een redelijke kloof tussen de puur technische patterns en de modellering patterns. Ik denk dat hier ontzettend veel braakliggend terrein is ontdekt. Ik ga er eens goed over nadenken.

    Geplaatst op 30 mei 2008 om 9:26 Permalink