Specificeren versus verifiëren

Unittesten is iets wat we inmiddels allemaal kennen. In een methode als Test Driven Development hebben we zelfs het doel om eerst de testen te specificeren en daarna de code (het gedrag) te implementeren. Dat klinkt goed en werkt ook goed als de applicatie architectuur het ondersteund. Dat we binnen Sogyo volgens een domein gedreven architectuur werken is inmiddels wel bekend en daar past deze stijl ook erg goed bij.

Op dit moment is er een interessante ontwikkeling gaande die vooral in de Ruby-wereld al uitgebreid toegepast wordt en met groot succes. Het gaat om specificatietalen. In zijn artikel A new look at Test Driven Development beschrijft Dave Atels op een beeldige manier wat het verschil is tussen de specificatietalen en testgedrevenheid. In essentie komt het neer op vooraf specificeren versus het achteraf verifiëren. Dan zou je kunnen zeggen “lekker spannend”. Echter wat het wat mij betreft interessant maakt is het feit dat je met specificatietalen dus vooraf formeel kunt beschrijven waaraan de implementatie moet voldoen. Je specifieert dus in een executeerbare taal. (Puur technisch gezien gelijkwaardig aan Unittest technieken). Dat zegt natuurlijk ook iets over de (lage) abstractie waarin de specificatie plaatsvindt. Die zou in dit geval op scenario niveau binnen een Use Case moeten liggen om concreet genoeg te zijn. Dat is mooi!
We hebben recent voor een klant een platform gerealiseerd waarin de ontkoppeling van het domein met de presentatie services plaatsvindt door “contracten” (of views op het domein) op Use Case niveau te definiëren. Dat betekent dus dat je een specificatietaal in moet kunnen zetten om tests voor deze contracten vooraf te schrijven. Interessant terein om verder te ontdekken.

Overigens zijn er best veel ontwikkelingen op gebied van specificatietalen. RSpec is in de Ruby-wereld een heel bekende. JBehave en NBehave lijken goede alternatieven voor Java en .NET. Maar ook Microsoft zelf is druk bezig met een implementatie. Je moet er nog even voor op zoek binnen Microsoft Research, maar Spec# klinkt veelbelovend.

Gepubliceerd op
Gecategoriseerd als Blog

SDC presentatie

Afgelopen dinsdag heb ik op de SDC een korte presentatie over DDD en DSL gegeven. Tijdens deze sessie heb ik laten zien hoe je met een horizontale DSL ondersteuning kan leveren voor NHibernate persisitentie in een domein gedreven architectuur. We hebben met name discussie gevoerd en demo’s bekeken. De ondersteunende slides voor de sessie vind je hier: DDD en DSL een mooie combinatie!.

Vanuit Sogyo overwegen we de DSL voor NHibernate open source te gaan maken. Er moet dan nog eerst een aantal uitbreidingen doorgevoerd worden die we op onze wensen lijst hebben staan. Interessante van deze DSL is dat je geen zorgen meer hoeft te maken over het maken van de mapping en configuratie files. Dit levert op dat bijvoorbeeld front-end ontwikkelaars hun werk kunnen persisiteren zonder diepgaande kennis over NHibernate te hebben. Het verbergt dus een deel van de complexiteit. Dit is wat mij betreft ook de grootste toegevoegde waarde van DSL. Interessant genoeg om er verder mee aan de slag te gaan.

Mocht je er meer over willen lezen. Samen met Andre Boonzaaijer ben ik een artikel aan het schrijven voor Software Release Magazine hierover. Wil je meer tijd vrij maken dan is het boek van Steve Cook echt het aanraden waar: Domain-Specific Languages with Visual Studio Tools een aanrader.

Gepubliceerd op
Gecategoriseerd als Blog

Ontmoeting Eric Evans

5 juli was er een besloten bijeenkomst waarin Eric Evans een korte introductie gaf in zijn werk rondom Domain Driven Design. Een zeer interessante dag. We hebben discussies gevoerd over modeleerstijlen. Wat me het meeste opviel is dat Evans vrij vroeg in het design proces rekening houd met techniek. Op zichzelf voelt dat goed, omdat je dan ook pragmatisch te werk gaat. Wat minder goed aanvoelt is dat wat mij betreft het domein altijd los staat van techniek. Hij heeft ruime tijd stil gestaan bij het concept van Ubiquitous Language. Dit is ook een van de punten die mij het meeste trekt in zijn werk. Het idee is dat je opzoek gaat naar de taal van het business domein. Samen met domeinexpert probeer je de termen boven water te krijgen die voor de business waardevol zijn. Daarbij gaf hij zeer bruikbare tips hoe dit verder uit te voeren.
 
Eigenlijk was een dag te kort. Juist als het echt interessant wordt is de dag voorbij. Een van de belangrijkste punten die nog openstaan is de relatie van de ambiguous language met OO ontwerpregels. In onze praktijk streven we namelijk zoveel mogelijk na om de termen uit de business rechtstreeks in een domeinmodel te modeleren. Echter naast de termen gaat het ook om verantwoordelijkheden die in een domeinmodel belegd moeten worden. De verantwoordelijkheden moeten dusdanig ingevuld worden dat het domeinmodel volledig op zichzelf de scenario’s van de use cases kan vervullen. Dan gelden dus ook de OO ontwerpregels voor een domeinmodel.
 
In ieder geval een leuke dag. Zeker de moeite waard om met hem verder te gaan mailen.. Wie weet komt er weer een vervolg. Een interessante man om verder mee te praten.
 
Gepubliceerd op
Gecategoriseerd als Blog, DDD