programmera.net -> architecture -> normal     för utskrift      info@programmera.net

Ubiquitous language

1. Varför bör projektet ha ett Ubiquitous language?
2. Hur används Ubiquitous Language?
3. Hur skapar man ett ubiquitous language?

1. Varför bör projektet ha ett Ubiquitous language?

Varför är det då så viktigt att mjukvaran programmeras med samma termer som domänexperten använder?

  • Syftet med ubiquitous language är att underlätta kommunikation inom gruppen.
För att illustrera hur det ofta ser ut i ett typiskt företag tittar vi på följande exempel:
  • Exempel: En nyanställd programmerare söker upp en domänexpert för att diskutera vidareutveckling av systemet. Programmeraren använder namn på objekt i mjukvaran för att beskriva sitt problem, eftersom dessa namn är troligtvis de enda han/hon känner till. Vi utgår från att de termer som används i koden är påhittade i stundens hetta och inte helt motsvaras av de termer som domänexperten använder. Domänexperten kommer inte att känna till den exakta betydelsen av dessa termer så som den ter sig för programmeraren. Därför måste domänexperten lära sig dessa termer för att underlätta kommunikationen med programmeraren. Även programmeraren måste bli "tvåspråkig" för att förstå domänexpertern.
Personer som länge har haft kontakt med "den andra sidan" blir "översättare" åt sina likar. För mycket tid ägnas åt ad hoc översättningar mellan domänexperter och tekniker. När systemet åldras i organisationen kommer de termer som domänexperterna använder och de termer som används i systemet att långsamt flyta ihop och bli en ohelig blandning av de båda språken. I DDD vill man undvika denna situation genom en medveten satsning på ett överallt förekommande språk, the ubiquitous language.

2. Hur används Ubiquitous Language?

Ubiquitous language är en uppsättning med termer som används av alla medlemmar av projektet när problemdomänen ska diskuteras. Till exempel ska ubiquitous language användas i följande situationer:

  • När man diskuterar med domänexperten
  • När programmerare diskuterar sinsemellan
  • I kravspecifikationen
  • I koden
  • I dokumentationen
Att gruppen enas om att bara använda en mängd klart definierade termer i sitt arbete är något som kräver ett visst engagemang av gruppen. För att lyckas med detta krävs någon form av samordning, ett dokument kanske med samtliga termer definierade. Man gör heller ingen vidare åtskillnad på termerna och själva domänmodellen, eftersom definitionerna av termerna i ubiquitous language utgör själva modellen. En förändring i ubiquitous language medför alltid en förändring av modellen.

3. Hur skapar man ett ubiquitous language?

Ubiquitous language skapas i en dialog mellan programmerare och domänexperter. Ubiquitous language har sin bas i de termer som domänexperten använder, men endast vissa synonymer väljs ut och upphöjs till termer i ubiquitous language. Programmerarna ställer krav på att språket ska vara sammanhängande och vara relevant för systemutveckling.

  • Det är fullt tillåtet för domänexperter att använda sitt vanliga språk när de diskuterar och förklarar olika termer, men de måste förstå att de termer som tillhör ubiquitous language har en mycket mer precis innebörd än vad de är vana vid, eftersom termen nu är BÅDE är en term inom domänområdet och en term inom systemutveckling, typiskt ett namn på en klass.
Innan nya termer läggs in i projektets ubiquitous language har man ett brainstormingmöte där målet är att kasta fram många förslag och kläcka nya idéer. Det är bra att illustrera modellen på en whiteboard med pilar och boxar. Mötet ska inte pågå för länge, och de termer man bestämt sig för är inte helt bestämda förrän man kan visa att de även fungerar i kod. Kanske framkommer någon faktor vid programmering som kräver en ytterligare uppdelning av problemet, och hålls ett nytt möte o.s.v.
  • Ett livligt experimenterande med språk är ganska ovanligt bland programmerare, detta är en teknik som är grundläggande för DDD eftersom det är så ubiquitous language kommer till. En viktig del handlar om att lyssna på domänexpertes ordval och att inte försöka "vinna diskussionen".
Domänexpertens samarbete är helt avgörande för DDD. Mötena ska vara prestigeslösa och får inte innehålla för många personer, eftersom detta medför en formellare tongång.