0
Het bijzondere van het 4dotnet blog is dat er ontwikkelaars op schrijven met verschillende achtergronden. Bijna iedereen heeft wel iets met Delphi. We hebben er bijna allemaal vroeger veel mee gewerkt. Voor de een is het nu een dierbare herinnering, op vloeiende wijze overgegaan in C#. En voor de ander is het nog steeds de favoriete taal om applicaties in te bouwen. En dat kan leiden tot niet altijd even zinnige maar toch altijd wel zeer vermakelijke discussies.
Maar uiteindelijk maken we applicaties voor opdrachtgevers. Voor de meesten van hen is het lood om oud ijzer in wat voor taal het product wordt gerealiseerd, beide talen zijn even onbegrijpelijk. Wat voor hen wel telt is de kwaliteit van de tool, levert het stabiele en snelle programma’s op? En hoe is de toekomstverwachting voor het product, is het nog up to date als de applicatie over een paar jaar uitgebreid moet worden?
Maar ook daar wil het niet over hebben. Het echte punt is de taal die je met je opdrachtgever spreekt. In welke woorden praat je over de applicatie? Hoe benoem je de beheerde gegevens en hoe wordt de functionaliteit gepresenteerd aan de uiteindelijke gebruiker? Hier kom je in de praktijk verschillende zaken tegen. Wat gegevens betreft heb ik vaak gezien dat het database ontwerp aan de opdrachtgever wordt gepresenteerd. En daarnaast een aantal verhaaltjes (user stories) die de functionaliteit beschrijven: “De gebruiker vult hier de NAW gegevens in. Na het klikken van de Klaar knop worden de gegevens opgeslagen en wordt de factuur geprint.” Om de koppeling tussen de tabellen in de database en de gegevenselementen in het verhaal duidelijk te maken kost vaak al wat meer moeite.
Aan de hand van een heel eenvoudig praktijkvoorbeeld wil ik het hier hebben over een manier om eenduidig, voor ontwikkelaar èn opdrachtgever, een (deel van een) applicatie te beschrijven en bouwen. De applicatie is een index voor de verschillende artikelen die ik zelf her en der op het web heb gepubliceerd. De artikelen worden in (meerdere) categorieën ingedeeld en het is ook van belang te kunnen kiezen op jaar van publicatie. Niets verouderd zo snel als softwaretools.
In dit geval ben ik dus zowel opdracht gever als uitvoerder. Niet een alledaags scenario, maar dat maakt het wel makkelijker om de essentie goed te kunnen presenteren.
Centraal staat hier een model met als entiteiten Publication, Subject en Publisher. Die eigenschappen en functionaliteit beschrijf ik in een aantal C# (Delphi of VB mag ook) classes. Van deze classes maak ik met Visual Studio een diagram
Aan de hand van dit diagram kan je aan de ene kant heel goed overleggen met je opdrachtgever. Het beschrijft de eigenschappen en functionaliteit van een Publication, hij en jij kunnen beiden zo zien dat een publication (onder andere) een title en een publisher heeft. En je kan ook zien dat een Publication functionaliteit heeft, dat doet de method Publish. Voor de opdrachtgever is dit schema in feite alles wat die moet weten. Of en hoe de eigenschappen worden opgeslagen doet er voor hem niet toe. Wat er technisch allemaal komt kijken bij het daadwerkelijk publiceren zit hem in de code van de class. Hoe die werkt wil hij niet weten, hij wil alleen weten dat het werkt. En hij wil weten dat die actie afgevuurd kan worden na (bijvoorbeeld) het klikken van de een of andere knop.
Dit model staat centraal in de hele verder ontwikkeling van de applicatie. Er zijn twee essentiële verschillen met een database model. In de eerste plaats beschrijft het ook functionaliteit, in de vorm van de methodes van de classes. Maar daarnaast volgt het helemaal niet (de beperkingen van) het relationele database model. Om objecten van deze classes op te kunnen slaan in een database heb je een koppeltabel nodig om een Publication te kunnen koppelen aan meerder Subjects.
Voor iemand met technische database kennis is dit heel duidelijk. Maar het proberen uit te leggen aan je opdrachtgever is heel, heel moeilijk. En als je met dit model werkt ook helemaal niet nodig, het wordt een technisch implementatie detail. Of je al dan niet een O/R mapper gaat gebruiken om het op te lossen is hier niet van belang.
Wat zijn verder sterke kanten van een domeinmodel in code?
· Er is één centrale plek waar de applicatie wordt beschreven. Verander je het model dan verander je de code. Verander je de code, dan verandert je het model.
· Je praat in één en dezelfde taal. Als de opdrachtgever praat over de title van een publication dan heeft die het over een hele bepaalde property van een heel bepaalde class. Geen verwarring mogelijk.
Dit beschrijft de kern van Domain Driven Design waar je allemaal samen praat in een alomvattende taal (ubiquitous language). Misschien klinkt dat als een modewoord, de nieuwste hype op architectuurgebied. Maar volgens mij beschrijft het juist de kern waar het echt om gaat bij het ontwikkelen van applicaties. En het doet er helemaal niet toe of je nou C# of Delphi gebruikt, dat is een taal die je deelt met collega ontwikkelaar. Niet met opdrachtgevers.
:
Naar boven
