Business-To-Code

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.