DCI Architecture

 
13 april 2009

Via het blog van collega Rob Vens kwam ik een weekje terug een artikel tegen van Jim Coplien en Trygve Reenskaug over een nieuwe manier van OO denken. DCI staat hierbij voor Data, Context en Interaction. De moeite waard om helemaal door te nemen, en als aanvulling is er tevens een interessante forumdiscussie na te lezen. Ik zal pogen kort samen te vatten waar het in de kern om gaat.

Volgens de auteurs is OO volgens de ‘klassieke’ manier zoals in de jaren ’80 van de vorige eeuw uitgewerkt relatief slecht in het vertalen van mentale modellen van gebruikers van een systeem naar code. Een eindgebruiker zal een use-case altijd uitleggen als een sequence van stappen die hij onderneemt – in feite een algoritmische view op de use case. Als we dit vertalen naar een OO model gaan we deze stappen ‘verdelen’ over een aantal classes waardoor een netwerk van kleine methoden ontstaan die door de code verspreid worden.

Dit heeft nadelen voor wat betreft onderhoudbaarheid van de code. Het klassieke idee dat we alleen lokaal hoeven na te denken over verantwoordelijkheden en dat het model het als geheel wel op gaat lossen via een soort ‘emergent behaviour’ wordt door de auteurs min of meer afgeschoten. In plaats daarvan moeten we een plek zoeken in onze code die dit soort eindgebruikersalgoritmen op een centrale plaats vasthoudt, los van alle verschillende classes die erbij betrokken zijn.

DCI stelt dat er een nieuw concept nodig is voor de plaatsing van dit soort algoritmen: rollen. Rollen zijn gedragingen die objecten in verschillende contexten toebedeeld kunnen krijgen. Er wordt een voorbeeld aangedragen in het bronartikel van bankrekeningen die verschillende rollen op zich kunnen nemen in een overschijving: source en destinationaccount. Al naargelang de context die geschapen wordt kan een account een verschillende rol vervullen. De basis class van deze bankrekeningen is een ‘domme’ class die alleen data en simpele operaties als verhogen/verlagen van het saldo bevat. De echte businesslogica wordt in rollen uitgewerkt zodat de algoritmen voor bijvoorbeeld overschijvingen als geheel terug te vinden zijn in de code. Deze rollen worden dan runtime contextafhankelijk aan de objecten toegewezen via programmeerconstructies als mixins of traits (ik ga daar nu niet op in). De problematiek om verantwoordelijkheden en gedrag te distribueren over een model heb ik zelf al eens wat over op papier gezet.

Dit artikel heeft mij aan het denken gezet. Vaak is het zo dat het erg lastig is om verantwoordelijkheden goed te leggen in domeinmodellen. Gesteld dat we een overboeking willen modelleren, welke account is dan verantwoordelijk voor deze actie – source of destination? De state van beide accounts wordt gemanipuleerd dus in feite wringt er iets in deze versimpelde collaboratie. Als ik puur vanuit een modelleerperspectief kijk dan zou ik ook zeggen dat er een transactie object in het model nodig zou zijn. Hier stappen de auteurs overheen; de transactie is alleen aanwezig in het algortime en wordt verder niet als gevolg van deze actie opgeslagen (ik kan een transactieoverzicht op mijn rekening toch wel waarderen). Daarnaast ben ik er niet zeker van dat rollen het gestelde probleem op gaan lossen. We verplaatsen immers alleen de logica, om het echte probleem op te lossen moeten we juist meer procedureel gaan denken. Als ik verschillende kleine rollen definieer en hierover de algoritmen verdeel heb ik nog steeds het probleem dat mijn use-cases verweven zijn door de code, alleen nu door rollen i.p.v. classes.

De conclusie die ik eruit trek is dat te stricte toepassing van OO denken leidt tot distributie van algoritmen over verschillende classes. Dit heeft als nadeel dat de code minder transparant is en slecht mapt op mentale modellen van eindgebruikers. Om deze modellen beter terug te laten komen in de code zullen we op een meer procedurele manier moeten programmeren. Of DCI hiervoor nu de ideale manier is weet ik niet, Evans/Fowler etcetera praten ook binnen Domain Driven Design over een ‘application layer’ die deze mapping faciliteert. Ikzelf ben technisch gesproken ook een voorstander van het werken met een 4-laags model, waarin er een (service)laag is opgenomen die ‘bovenop’ het domeinmodel draait die helder aangeeft welke use cases (of contracts, of services) het onderliggende model aanbiedt. Zo kunnen we in deze tussenlaag exact aangeven waar de entry-points voor de use cases in het model liggen.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development


Reacties (4)

  • Rick schreef:

    @André: ik heb het artikel over ObjectTeams wat Arno aanhaalt ook gelezen en dit artikel waar je naar linkt nu ook. Moet zeggen dat ik niet echt overtuigd ben.

    De auteurs klagen dat er geen plek is om gedrag eenduidig te plaatsen in een OO model. Nou, die is er volgens mij wel, namelijk: een object. :-) Het artikel gaat nog wel heel erg uit van de te-kort-door-de-bocht vuistregel die luidt: zelfstandige naamwoorden zijn objecten, werkwoorden zijn methodes. Volgens mij kunnen werkwoorden ook objecten zijn. Je kunt ze dan overigens ook vaak omschrijven met een zelfstandig naamwoord. Inderdaad, het voorbeeld wat je ook al aanhaalt met de transacties.

    Veel van de objecten waar we mee te maken hebben op de werkvloer, buiten de computer, zijn vaak passief. Maar dat betekent helemaal niet dat we alleen gewend zijn om met passieve objecten om te gaan. Denk eens aan het kopieerapparaat, maar ook aan keukenhulpmiddelen of zelfs huisdieren. Het leuke van de vrijheid die software ons geeft is dat deze ons in staat stelt om objecten te maken die een activiteit representeren of in ieder geval op een bepaalde manier actief zijn.

    Ik denk dat de schrijvers iets te ver door willen voeren dat objecten in software overeen moeten komen met de wereld buiten de software. Ze hoeven volgens mij niet allemaal direct herleidbaar te zijn naar een (eerder) bestaand object. Dan zouden we gebonden zijn aan de objecten die mensen nu al kennen. OO modellen maken alleen gebruik van de bekendheid van het menselijk brein met objecten, meer niet. Ik denk hierbij natuurlijk ook aan de ‘spiegelwereld’ van onze collega Rob Vens.

    Het is mijn ervaring (en niet alleen de mijne) dat mensen die nog weinig begrip hebben gevormd van hun omgeving, denken in scripts. Als dat gebeurd, dan doe ik dat en daarna zus, even wachten op zo. Het lastige daarvan is dat het maar heel beperkt werkt. Als iets afwijkt van hetgeen dat in het script staat, houdt het op. Je moet toch echt eerst een mentaal model vormen van hetgeen je mee bezig bent om er nieuwe situaties mee aan te kunnen. Ik denk dat de schrijvers van dit artikel de behoefte voelen om heel veel te scripten buiten een door hen gemaakte oo-structuur om, omdat de door hen gemaakte modellen nog niet volledig (actief) genoeg zijn.

    Geplaatst op 19 april 2009 om 19:49 Permalink

  • Matthijs Holsbrink schreef:

    Rollen in .NET:

    http://www.infoq.com/presentations/Making-Roles-Explicit-Udi-Dahan

    Volgens mij werd hier ook naar verwezen tijdens de DCI seminar op J-Spring, maar dat weet ik niet zeker.

    Geplaatst op 17 april 2009 om 19:21 Permalink

  • Hier: http://www.artima.com/forums/flat.jsp?forum=226&thread=253008&start=15&msRange=15 staat wel een uitwerking van Christian Horsdal in C#. Hij gebruikt interfaces en extension methods om de rollen te definieren en implementeren. Interessant :).

    Geplaatst op 13 april 2009 om 21:54 Permalink

  • Arno schreef:

    Klinkt een beetje als ObjectTeams (http://trac.objectteams.org/ot/wiki/OTJ) in Java. Worden rollen ook expliciet gemaakt in het samenwerken van objecten.
    Stond laatst een leuk artikel over in het NL-JUG blad, de moeite van het nazoeken waard.
    Woensdag 15 april op de J-Spring is er ook een presentatie over DCI waarbij, volgens de aankondiging (http://www.nljug.org/pages/events/content/jspring_2009/sessions/00015/) ook ingegaan wordt op ObjectTeams en andere libraries.

    Enig idee of er aan de .Net kant ook al dit soort initiatieven zijn?

    Geplaatst op 13 april 2009 om 20:53 Permalink