Hva er en domenemodell - egentlig?

I boka "Patterns of Enterprise Application Architecture" (P of EAA) beskriver Martin Fowler "Domain Model" som en modell som omfatter både data og oppførsel innenfor et domene. Men hvordan omsette dette til tjenester og interfaces?

Abstraksjon av data og funksjonalitet

Domenemodellen er en abstraksjon av data og funksjonalitet innenfor et område. Modellen er med andre ord ikke kode skrevet i WSDL eller XML, men en beskrivelse av domenet.

Fowlers domenemodell fra P of EAA knyttes fort opp mot en implementasjon i J2EE. Selv om Fowler påpeker en del av problemene med EJB får fort domenemodellen en farge av programmeringsspråk som gjør at vi mister litt av det jeg mener må være de primære hensiktene med en domenemodell: Å være et medium til å kommunisere med de som virkelig forstår domenet og for å kunne skape en god oversikt over hva funksjonaliteten i problemdomenet er.

Modellen blir da en høynivå oversikt og kan brukes til å kartlegge hvilke deler av modellen som kan realiseres med it-systemer.

Domeneekspertene skjønner ikke WSDL, Java eller annen bytecode, men begreper som Kunde, Ordre og handel. Programmeringsspråk er dårlig egnet til å gi en slik oversikt over hva domenet består i.

Selv om programmereren i meg flere ganger har forsøkt å overbevise ikke-programmerere om at det går fint å lese både Java og WSDL med litt trening, må jeg vel innse at terskelen fort blir høy. For høy til at det vil fungere i et prosjekt fordi man må trekke domeneeksperten langt over på IT-siden før man får gjort noe som helst.

I et utviklerperspektiv er det nyttig å ha modellen nært implementasjonen. Det er tross alt utvikleren som vil være nærmest funksjonaliteten når systemet realiseres, men er det fornuftig at utvikleren "eier" modellen på denne måten? Modellen kan da fort bli forurenset av tekniske aspekter og begrensninger og mister sin egenskap som beskrivelse av hva virksomheten består i.

Modelldrevet utvikling

I den andre enden kunne vi latt domeneeksperten vedlikeholde modellen, men da er det igjen stor fare for at kartet mister kontakten med terrenget. D.v.s. at modellen fjerner seg fra den faktiske realiseringen.

Jeg har lest flere av bloggene til Johan den Haan innenfor området og ser at han mener at en modelldrevet utvikling er veien å gå. I hvert fall når man begynner å få litt størrelse på organisasjonene. Modelldrevet utvikling innebærer at modellen er grunnlag for senere implementasjoner. Dette står, etter min mening, litt i kontrast til XP og Scrum, som nesten ikke kan vente med å implementere så snart man får et krav, eller i noen tilfeller bare et innfall.

Ser domenet fra ulike perspektiver

Modelldrevet arkitektur har aspekter ved seg som vi kjenner igjen fra RUP: Viktigheten av å se domenet fra forskjellige perspektiver og utarbeide forskjellige modeller ut fra hvilket perspektiv vi ønsker å belyse:

• Beregningsuavhengig modell (CIM). Beskriver systemets eksterne funksjonalitet uavhengig av systemmessige sammenhenger. Beskriver modellens vokabular. Modellen er ment brukt som den prinære modellen i å bygge bru mellom domeneeksperten og de som skal sette sammen systemet.
  
• Plattformuavhengig modell (PIM). Beskriver systemets sammensetning/konstruksjon - hvordan systemet er tenkt å virke - uavhengig av plattform. Sammensetning av komponenter for å imøtekomme de funksjonelle kravene vil være en del av en slik modell.
  
• Plattformavhengig modell (PSM). Beskriver hvordan systemet tenkes implementert på en gitt plattform.

I tillegg til å belyse forskjellige perspektiver utgjør disse tre modellene forskjellige detaljeringsgrader i problemområdet. Vårt primære mål med domenemodellen er å ha en felles plattform for kommunikasjon med superbrukerne og et godt beslutningsgrunnlag for hva som skal realiseres som tjenester og hva som kan vente. Det er, med andre ord, den beregningsuavhengige modellen vi snakker om når vi snakker om en domenemodell i en tjenesteorientert arkitektur.