Wat is het domein?

 
13 januari 2009

Bij het implementeren van een domeingedreven ontwerp of DDD wordt een strikte scheiding aangehouden tussen het domein en de techniek.
Bij een applicatie voor een verzekeraar zijn typische domein onderdelen risico’s, dekkingen, schademeldingen, en dergelijke.
Techniek is alles wat te maken heeft met computers: databases, netwerkcommunicatie, user interfaces, en dergelijke.
Vaak is dit onderscheid niet moeilijk te maken en kunnen de ontwerpers bij het vaststellen van de scheidingslijn tussen domein en techniek dit zonder al te veel discussie doen.
Maar niet alle applicaties hebben zo’n duidelijk domein.
Vooral projecten die een min of meer technische oplossing moeten bieden merken dat ze ineens in discussies verzeild raken rondom de vraag: wat is nu eigenlijk het domein?

Een project waar wij tegen dit soort ambiguïteit aanliepen is bezig een plugin of hulpapplicatie te realiseren voor eXploratory Modelling of xM in VisualStudio.
Bij xM zijn ontwerpers samen met de klant of domeinexpert bezig het domein te modelleren, bijvoorbeeld een verzekeringsdomein.
Om dit domein goed te visualiseren is het nodig dat de hulpmiddelen, in dit geval rond VisualStudio van Microsoft, de deelnemers aan de modelleersessies helpen de domein objecten goed te visualiseren zonder dat daar een user interface voor wordt gemaakt.
Bijvoorbeeld: een deelnemer wil een nieuw risico aanmaken. Dit moet kunnen door in een soort van workspace of intermediate window iets te doen als
new Risico():
Waarna het betreffende object zichtbaar en manipuleerbaar moet worden, bijvoorbeeld zoals in de illustratie hieronder:

DomeinObjectDe methodes op het object (in dit geval is het een object en geen class) moeten daadwerkelijk uitgevoerd kunnen worden, bijvoorbeeld door een popup menu op het gevisualiseerde object.
De applicatie waarvoor de discussie ontstaat “wat is het domein?” is deze hulpapplicatie voor VisualStudio, waarin visualisaties als hierboven getoond mogelijk moeten zijn (voor de VisualStudio experts: het betreft een soort Object Bench).
Is het Risico object het domein? Dit ligt het meest voor de hand, immers de illustratie lijkt een soort user interface te zijn voor dit domein object. Toch leidt deze benadering tot problemen en discussies. Bijvoorbeeld voor het visualiseren van meerdere van dit soort domein objecten is het nodig de ontstane object graaf te bewaren en voor een volgende xM sessie weer “op te brengen”. Hiervoor moet bijvoorbeeld de layout van de objecten worden bewaard.
Een wezenlijker probleem is het opvragen met een popup menu van een methode van een domein object. Dit is niet iets dat typisch behoort tot het domein van de eindgebruiker, maar iets dat wel degelijk behoort tot het “domein” van deze applicatie.
Kortom, het lijkt erop aan te sturen dat voor dit soort applicaties een soort van “tussendomein” nodig is.
Dit is precies wat hier aan de hand is. Rondom de “echte” domein objecten als Risico en Dekking moeten wrappers worden geplaatst, en deze gewrapte objecten functioneren als de domein objecten voor onze applicatie.
Ik liep voor het eerst tegen dit pattern aan bij het ontwikkelen van SmallSim, één van mijn eerste projecten. Dit systeem biedt een platform aan voor het modelleren van complexe systemen, die vervolgens ook kunnen executeren – executable modellen kortom. Hierbij zijn ook de werkelijke domein objecten gewrapt. Het is belangrijk zich te realiseren dat deze gewrapte objecten, die de domein objecten zijn voor de applicatie, niet direct hetzelfde zijn als wrappers of adapters zoals we die normaal maken om domein objecten te koppelen met techniek (bijvoorbeeld Aspect Adapters).

Dit pattern kort samengevat:

  1. De beslissing welke objecten nu de domein objecten zijn voor onze applicatie is niet altijd evident
  2. Dit is vooral het geval bij meer technische applicaties
  3. Implementeer voor dit soort gevallen een laag om de betreffende objecten en behandel deze als de domein objecten voor de applicatie
  4. Maak niet de vergissing deze laag als een technische adapter laag te beschouwen

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


Categorieën: Development, Professionele vaardigheden, .Net


Reactie

  • Gerard Braad schreef:

    Deze tool mag geen Object Bench heten. Deze functionaliteit in VisualStudio is verre van ideaal om deze taken uit te voeren… vandaar ook het initiatief! Maar mijn vraag… zou je tijdens de xM visualisatie onderscheid maken tussen Entities en Value Objects? Of is dat een keus die je liever overlaat aan de ‘ontwikkelaar’?

    Geplaatst op 29 januari 2009 om 1:06 Permalink