SDN Architectuur track

Voor de SDN (Software Development Network) heb ik afgelopen jaar meerdere keren gesproken op zowel de events als de conferentie. Het zijn leuke bijeenkomsten met zeer uiteenlopende onderwerpen. Sinds dit voorjaar heeft de SDN besloten een aantal van haar track te herzien en uit te bereiden. Een van de uitbreidingen is de introductie van de architectuur track. Het doel van deze track wordt software architectuur als een losse pijler neer te zetten.

Software architectuur heeft ook mijn interesse en daarom hebben we besloten dat de SDN te helpen deze architectuur track op te zetten. Als track lead ga ik me inspannen om interessante sprekers en auteurs te benaderen en de track verder vorm te geven. Dus mocht je interessante artikelen hebben of willen spreken laat het dan horen. Anders zie ik je graag op een van de bijeenkomsten die je op de site kunt terug vinden.

Gepubliceerd op
Gecategoriseerd als Blog

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

Enterprise architect en applicatie-architect: hoe kunnen ze elkaar begrijpen ?

Tijdens een bijeenkomst op 19 maart van het Studiecentrum voor Automatische Informatieverwerking in Brussel ga ik met Rob Vens in disucssie over IT architectuur. Rob heeft jaren lange ervaring als Enterprise Architect en zal vanuit zijn achtergrond kijken naar de architectuur. Zelf heb ik ruime ervaring in applicatie (software) architectuur. Tijdens deze discussie zullen we met name de verschillende perspectieven belichten. Ondanks het feit dat Rob en ik veel samenwerken en in veel ideeen overeenstemmen wordt het zeker een spannende discussie.
Voor praktische informatie over de sessie moet je op de site van de SAI zijn.

Deze sessie is een afgeleide van de sessie die we voor de NLJUG hebben gedaan tijdens de J-Fall.

Gepubliceerd op
Gecategoriseerd als Agenda

DDD en DSL: een mooie combinatie!

Werken met een domeingedreven applicatie architectuur is mooi. Daarnaast zien we nu veel gesproken worden over DSL. Zeker in de Microsoft wereld is dit een hot topic. In dit artikel hebben we kort beschreven hoe DSL’s gebruikt kunnen worden in een domeingedreven ontwikkelomgeving. Het artikel:
DDD en DSL.

Overigens binnen Sogyo hebben een DSL ontwikkeld om NHibernate mappings en configuraties bestanden te genereren. Een goed voorbeeld van een horizontale DSL die vooral veel herhalend werk uit handen neemt. Mocht je hiermee aan de slag willen stuur dan ff een mailtje.

Gepubliceerd op
Gecategoriseerd als Publicatie

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

Waar ligt de essentie van jouw software?

Hierboven staat een vraag die je niet dagelijks zult krijgen. Toch is het in de software ontwikkeling wel één van de belangrijkste dingen om bij stil te staan. Waar draait het nu eigenlijk om in je software? Draait je software om de database? Draait het om de User Interface?

Het zou kunnen dat je veel gegevens opslaat en muteert. Dan is de database belangrijk, maar in dat geval betekent dat, dat je veel CRUD-activiteiten uitvoert. Daar ligt immers de kracht van onze relationele databases.

Als het om de UI draait, zijn vanzelfsprekend de schermen die onze gebruikers te zien krijgen van belang. De schermen zijn vaak het aanknopingspunt met de gebruikers van de software: door de functionaliteit te visualiseren, wordt immers voor de gebruiker duidelijk wat de software zou moeten doen.

Dit alles neemt niet weg, dat we de essentie van de meeste software niet terugvinden in de databases of de UI. Om de essentie van software vast te stellen is het handig een blik te werpen op het werk van Fredrik Brooks. In “No Silver Bullet” beschrijft hij het verschil tussen de essential complexity en accidental complexity. Vrij vertaald zegt hij daarin dat we in onze software onderscheid moeten maken tussen de delen die de kernproblematiek (essential) ondersteunen en alle faciliterende logica (accidental). Wanneer we dat relateren aan de software die we maken, dan gaat het in de kern om de logica die onze businessprocessen ondersteunen. De essentie van onze software vinden we dan dus niet terug in de database of UI. Daar willen we immers de businesslogica niet in plaatsen.

Dit maakt dat Domain Driven Design op dit moment zoveel aandacht geniet: alleen in een domeinmodel plaatsen we namelijk puur en alleen alle logica die onze businessprocessen representeert. Om deze kern van logica draait onze software. Dat is de essentie!

Als het domein (met daarin de businesslogica) de essentie is, dan is volgens het denken van Brooks de overige logica slechts faciliterend. Deze overige logica zorgt ervoor dat we in staat zijn ons domein in haar levencyclus te ondersteunen. Anders gezegd: het domein (dat de businessprocessen ondersteunt) maakt de software uniek.

De faciliterende onderdelen zijn niet uniek voor het domein. Daarom kunnen die onderdelen generiek gemaakt worden en makkelijk hergebruikt worden om verschillende domeinen te ondersteunen. Deze logica kan in frameworks belanden, of misschien zelfs in taal. Technieken als Domein Specific Languages maken het mogelijk om deze functionaliteit in tekstuele dan wel visuele talen te plaatsen. Vervolgens kan vanuit deze talen de concrete implementatie genereert worden.

Ondanks het feit dat het soms lijkt dat onze software draait om de database of de schermen, blijkt dat de businesslogica de uiteindelijke kern vormt. Door deze centraal te stellen en onafhankelijk te maken van alle andere code eromheen, leggen we daar de focus op in onze software. De overige onderdelen kunnen we daarna genereren of zoveel mogelijk in standaard frameworks plaatsen. Wanneer je frameworks als Spring of Seam toepast, is het goed om de essentie van je software in de gaten te houden. Zorg er dus voor dat deze frameworks je businessdomein faciliteren!

Gepubliceerd op
Gecategoriseerd als Publicatie

DDD in de praktijk

Dit artikel is verschenen in de New Stuff (het blad van de SDN) van April 2007. We (Andre Boonzaaijer en ik) zetten in het artikel een aantal implementatie strategieen uiteen. Goed om over na te denken om te zien welke oplossing het beste werkt in je eigen partijk. Download het artikel in PDF DDD in de praktijk.

Gepubliceerd op
Gecategoriseerd als Publicatie

Domain Driven Design and Lego Mindstorms NXT

Met Lego Mindstorms wil ik duidelijk maken hoe Domain Driven Design in de praktijk toegepast kan worden. In dit voorbeeld heb ik een implementatie gemaakt om een Robot aan te sturen.

De implementatie is gemaakt in Microsoft .NET 2.0. Je kunt hem hier downloaden. Om de applicatie te laten werken heb je de NXT nodig. Deze kan via bluetooth met  je PC communiceren. In de sources van de applicatie vindt je, in de services map, een class MindStormService. Deze class bevat een constante die de COM-port weergeeft voor de bluetooth communicatie.

Deze implementatie maakt overigens gebruik van NXT#. Dit is de LegoMindstorms Interface die te vinden is op: NXTsharp.fokke.net.

 

Gepubliceerd op
Gecategoriseerd als Demo