UL på svenska

[Jonas Lindström]

Jag utvecklar både standardprodukteroch kundspecifika lösningar men
har hittills kodat och modellerat på engelska. Orsaken är nog mest
slentrian, jag tog beslutet för många år sedan och det har hängt med
sedan dess.

När jag nu börjat titta på DDD uppstår frågan:

Hur hanterar man bäst Ubiquitous Language? Modellera på svenska eller
engelska?

Jag utvecklar standardprodukter som i dagsläget är riktade mot den
svenska marknaden men förväntas kunna marknadsföras internationellt.
Här verkar det rimligt att använda engelska, trots att mina
domänexperter för tillfället är svenskar. (En intressant bonus är att
eftersom produkterna innehåller UI på svenska och engelska kan de
användas i multinationella organisationer.)

Ett exempel på kundspecifik lösning: En industri nyttjar ett MPS-
system som har engelska termer. De har ett rapportsystem som hämtar
data från MPS-systemet. Engelska termer i MPS-systemet översätts till
svenska i rapportsystemet. Här uppstår potentiellt ett problem när
användarna diskuterar domänen beroende om man pratar om MPS-systemet
eller en rapport.

Vad är din erfarenhet?

[Peter Backlund]

2010/1/16 Jonas Lindström <jonas.e...@gmail.com>:

> Jag utvecklar både standardprodukteroch kundspecifika lösningar men
> har hittills kodat och modellerat på engelska. Orsaken är nog mest
> slentrian, jag tog beslutet för många år sedan och det har hängt med
> sedan dess.
>
> När jag nu börjat titta på DDD uppstår frågan:
>
> Hur hanterar man bäst Ubiquitous Language? Modellera på svenska eller
> engelska?

Min erfarenhet är att det är en stor fördel att använda svenska i
domänmodellen/-lagret om man har möjlighet att göra det och alla
inblandade kommunicerar på svenska. Det är helt enkelt en naturlig
konsekvens av idén om UL. De flesta (inkluderade mig tidigare) rynkar
på näsan vid fösta anblick, eftersom det är ovant, man blandar svenska
och engelska (nyckelord) och det ser lite nybörjaraktigt ut (tänk
Skansholm - Java Direkt). Jag skrev ett litet utkast till modell kring
en bloggpost där koden är på svenska som man kan kika på för att få en
känsla för hur det skulle kunna vara:

http://github.com/peterbacklund/mdic/tree/master/src/rma/

som hör till

http://peterbacklund.blogspot.com/2009/10/med-domanen-i-centrum_8234.html

Visst, jobbar man en internationellt är det inte alltid möjligt, men
man kan exempelvis exponera API:er mot andra system som är på
engelska. I vissa domäner är de engelska termerna kanske oerhört väl
inarbetade även i en svensk organisation, så där är det kanske av
mindre värde att programmera på svenska.

> Jag utvecklar standardprodukter som i dagsläget är riktade mot den
> svenska marknaden men förväntas kunna marknadsföras internationellt.
> Här verkar det rimligt att använda engelska, trots att mina
> domänexperter för tillfället är svenskar. (En intressant bonus är att
> eftersom produkterna innehåller UI på svenska och engelska kan de
> användas i multinationella organisationer.)

Att det finns användargränssnitt och användare som använder det
engelska språket tvingar inte UL att vara på engelska, utan det
viktiga är att kunskapsöverföring och -strukturering från DE til
utvecklare sker på ett så friktionsfritt sätt som möjligt.

> Ett exempel på kundspecifik lösning: En industri nyttjar ett MPS-
> system som har engelska termer. De har ett rapportsystem som hämtar
> data från MPS-systemet. Engelska termer i MPS-systemet översätts till
> svenska i rapportsystemet. Här uppstår potentiellt ett problem när
> användarna diskuterar domänen beroende om man pratar om MPS-systemet
> eller en rapport.

Det här låter som ett klassiskt exempel på två olika modeller (av
samma domän(?)) som lever i var sin bounded context. Det blir väldigt
tydligt när det dessutom involverar två olika språk. Jag skulle säga
att det bästa är att bejaka skillnaden och göra gränsen tydlig.

[Fredrik Klintebäck]

Fördelarna med engelska:

- underlättar om man ska lansera produkten internationellt, ta in utländska utvecklare osv
- övriga utvecklingen är på engelska
- inga "internationella tecken" som fortfarande kan ställa till problem

Nackdelen med engelska:

- svårt att översätta rätt (även om man är bra på engelska kanske man inte kan verksamhetsbegreppen)
- tar tid att översätta rätt
- problem när man pratar med användarna

Jag har nästan alltid utvecklat på engelska, senast ett skogligt system men det har tagit tid att översätta och ofta blivit fel (vad heter planta på engelska, barrträd, gallring, plantering, slutavverkning osv). I det fallet har beställaren velat ha det på engelska och efterhand har vi gått in och rättat felaktiga översättningar, och det kan vara rätt tidsödande.

Just nu kör vi svengelska utan prickar, tex AvtalFactory, Leverantor osv.

--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen DDD Sverige i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till dddsv...@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till dddsverige+...@googlegroups.com.
För fler alternativ, besök gruppen på http://groups.google.com/group/dddsverige?hl=sv.

[Peter Backlund]

> Just nu kör vi svengelska utan prickar, tex AvtalFactory, Leverantor osv.

Intressant, vi kör också pattern-namn på engelska och resten på
svenska (med åäö), typ ResursområdeRepository osv.

Vilka specifika problem stöter folk på med infrastruktur och svenska
tecken förresten? Jag har inte upptäckt något annat än att IntelliJ
inte kompletterar korrekt från CamelCase (typ ReRe ovan), och samma
sak med "öppna klass" (ctrl-n eller äpple-n). Annars funkar det
perfekt i SVN + IntelliJ + Java 6 + Maven + Mac/Win/Lin.

[Fredrik Klintebäck]

Hmm, ja det är nog mest för säkerhets skull vi kör det, en av mina kollegor sa han hade stött på ett problem med det men kommer inte ihåg var.

2010/1/16 Peter Backlund <peter.b...@gmail.com>

[Jonas Lindström]

@Peter, @Fredrik tack för svaren.

Skulle ni säga att ni lättare hittar rätt domänmodell genom att
använda svenska termer?

Är det någon som försöker sig på att även översätta mönsternamn?
PersonFabrik verkar lite... Konstigt ;)

Jag är mycket intresserad att prova svenska termer i mitt nästa
projekt.
Blir lite avundsjuk på dom som utvecklar för de engelskspråkiga
marknaderna. Med engelska som modersmål blir det ytterligare fördelar
som jag ser det.

Tack för länken till mdic-projektet, Peter. Snackar själv C# men med
närheten till Java så det blir definitivt en tillgång under mina
äventyr inom DDD.

Visual C++ 6.0 har haft problem med internationella tecken i
programkod. Antar att problemen är färre (borta?) i nyare versioner av
Microsofts utvecklingsprodukter. Att klippa "prickarna" på å, ä och ö
verkar ändå vara lämpligt.

[Dan Bergh Johnsson]

Skulle ni säga att ni lättare hittar rätt domänmodell genom att
använda svenska termer?

Det som gör skillnad tycker jag är att ett språk är just så mycket mer än bara termer, det är även t ex meningsbyggnad och idiom. Och även ett UL för en modell kommer ganska snabbt att få "vanliga fraser" och "så brukar vi säga". Så, för mig känner jag att det inte är huruvida termerna är på svenska som gör skillnaden utan hur bra jag kan använda språkkänslan.

Jag tycker att jag definitivt har bättre språkkänsla på svenska som är mitt modersmål, än på engelska som jag visserligen känner mig bekväm med, men inte är mitt modersmål. (Intressant test för datafolk som tycker de kan engelska: laga en enkel måltid i köket och beskriv vad du gör, vilka redskap du använder etc, spela in och lyssna därefter på inspelningen. Mycket bra för ödmjukheten)

Så, visst tycker jag att det gör skillnad, och jag föredrar att basera min modell på svenska om jag har ett val. Men för min del är det språkkänslan som är avgörande, inte de enskilda termerna - ett engelskt, tyskt eller franskt låneord här och var har aldrig skadat ett språk, snarare tvärt om.

En viktig sak i dethär sammanhanget är att man måste komma ihåg att domänspråket (som domänexperter pratar sig emellan) och domänmodellspråket (som är allas gemensamma UL när vi diskuterar systemet) är två distinkta språk, även om de skulle båda vara baserade på svenska (eller engelska). Så när våra dyk-domän-experter säger "navelsträng" så kanske det inte nödvändigtvis är exakt samma sak som när vi pratar om "navelsträng" i DM-språket för regler kring dykning.

Skrev en blogpost om detta nyligen: domänspråk och domänmodellspråk. 

Är det någon som försöker sig på att även översätta mönsternamn?
PersonFabrik verkar lite... Konstigt ;)

Nej, det etablerade UL som finns för att diskutera pattern-baserade designer har termer som är väldefinerade. Det pattern-språk som bygger på GoF har termer som är definierade med synnerlig precision; det är ingen diskussion om vad ett "Abstract Factory"  är. Att börja "översätta" de termerna för att skapa ett separat design-pattern-UL "på svenska" känns väldigt omotiverat för mig.

"Konstigt" var ordet, sa Bull.

 

Jag är mycket intresserad att prova svenska termer i mitt nästa
projekt.
Blir lite avundsjuk på dom som utvecklar för de engelskspråkiga
marknaderna. Med engelska som modersmål blir det ytterligare fördelar
som jag ser det.

För min del ser jag en enorm fördel att ha två språk som jag rör mig bekvämt med. När jag fastnar i det ena kan jag alltid gå över i det andra och försöka hitta andra ord eller uttryck som kanske rör mig närmare vad jag vill uttrycka. 

Jag har också använt just svenska vs engelska just för att poängtera skillnaden mellan "dagligt domänexperttal" och "systemprat" genom att föra allmänna resonemang på svenska för att sedan ta den engelska termen som DM/UL-term och ladda denna med en väldigt precis innebörd. 

domänexpert: "jadda, jadda, skicka notifieringar och avisera, jadda jadda"

Dan: "Så kan vi med 'notification' mena ..."

Så, även om jag gärna har mitt UL på svenska så tycker jag inte det är så viktigt. 

   DDDan

[Jonas Lindström]

Tack Domän-Drivna-Dan ;)

Lysande idé om att testa språkkunskapen i köket! Hade själv en önskan
om att introducera engelska språket för min femåriga lilla flicka, men
efter närmare eftertanke kan jag bara konstatera att jag kan "dator-
engelska". Ord utanför datorernas värld är jag inte lika säker på.

Har samma uppfattning om dig vad gäller termer för patterns.

När jag utvecklar standardsystem försöker jag generalisera alla termer
så långt det går. I ett fall har jag använt en språkresurs (per språk)
som tillåter slutanvändaren att själv definiera termer i
användargränssnittet. Standardbenämningen Kategori kanske kallas Klass
eller Område. Har fungerat bra men kan försvåra samtalet vid support-
ärenden.

Tydlig och bra artikel om UL, skulle vilja kalla den oumbärlig för
personer som är nya inom DDD, kommer väl till hands för mig i alla
fall. Läropengen kanske kan vara att inte hårddra idén om UL in
absurdum?

[Jimmy]

Precis som många andra här så gillar jag sedan några år tillbaka att
programmera på svenska när situationen är lämplig. Ett par kommentarer
från närtid om detta:

- "Men vi jobbar mycket med offshoring, hur skall de utvecklarna som
sitter på andra sidan jorden då kunna förstå?"

Jag tycker personligen att det är en olycklig anledning att välja
engelska av det skälet. Då optimerar man inte för kundkommunikationen,
utan någonting annat...

- Efter att vi jobbat ihop ett tag i ett nytt projekt (helt oberoende
av ovan kommentar) så sa en av utvecklarna: "Ah, vilken lättnad att
koda på svenska och t o m med svenska tecken!"

En annan sak i samma härade som slår mig är ordet "Repository". Det
har en tendens att smyga sig in i diskussioner med domänexperter och
det känns som att man varje gång får ta en ursäkt kring det hela,
vilket jag inte tycker är optimalt. Jag har slutat att använda det som
suffix på mina klasser. Jag tror mycket få av er använder t ex
ValueObject som suffix också, korrekt?
:-)

Mvh
Jimmy
###

[Fredrik Klintebäck]

Fast repository är ju inte riktigt ett suffix, säg att repository översätts till lager och factory till fabrik och vi jobbar med order så blir det ju

 

OrderLager, OrderFabrik och Order

 

Det är ju en sammansättning för att beskriva något annat än en entitet eller ett värdeobjekt, "här sparar vi undan och söker fram ordrar" och "här snickrar vi ihop nya ordrar".

 

Det ligger ju ett värde i andra delen av sammansättningen så att alla som håller på med DDD förstår vad det handlar om (precis som när man använder design patterns, kallar man saker Visitor, State, Strategy, Command osv förstår andra utvecklare vad som används).

 

Just denna typ av klasser är väl hur man än gör lite främmande för domänexperterna, eller?

 

Tjänster däremot ser jag att de gärna kan ha namn som beskriver mer vad de gör utan att de slutar på tjänst/service.

2010/1/17 Jimmy <Jimmy....@jnsk.se>

[Dan Bergh Johnsson]

2010/1/17 Jimmy <Jimmy....@jnsk.se>

En annan sak i samma härade som slår mig är ordet "Repository". Det
har en tendens att smyga sig in i diskussioner med domänexperter och
det känns som att man varje gång får ta en ursäkt kring det hela,
vilket jag inte tycker är optimalt. Jag har slutat att använda det som
suffix på mina klasser. Jag tror mycket få av er använder t ex
ValueObject som suffix också, korrekt?
:-)

Väldigt närrelaterat funderade jag på hur andra gör när det finns "naturliga repository". Om man till exempel har en uppsättning böcker skulle man mycket väl kunna tänka sig att objektet man uppsöker för att finna sådana är ett "bibliotek". 

Den mentala bilden är ju rätt intuitiv. Jag brukar själv hemmavid säga att jag "ska gå och hämta den [boken] i biblioteket" innan jag företar min tämligen korta promenad bort till mina tämligen oglamorösa billy-hyllor.

När ni andra programmerar, skulle ni göra en sådan metafor och kalla "BookRepository" (alt "BokRepository") för "Library" (alt "Bibliotek"), eller skulle ni hålla på "standard-formatet"?

   DDDan

[Fredrik Klintebäck]

Ja finns det ett naturligt repository skulle jag nog använda det tror jag, har dock inte stött på något sådant fall.

 

Är lite nyfiken på vad Jimmy har för namn istället förresten.

 

Lite OT: Någon som stött på "konstiga" domännamn någon gång? Själv minns jag när vi höll på med domänmodellering på SJ för en 12-13 år sedan, ett väldigt centralt begrepp för dem var "Relation" (tror ungefär samma begrepp finns i Evans bok, men där heter det Route).

 

 

2010/1/17 Dan Bergh Johnsson <dan.bergh...@gmail.com>

[Marcus Hammarberg]

Hej, 

Mycket intressant diskussion som väldigt ofta kommer upp... 

Håller först och främst med om att det är svenska som gäller - så länge vi är i Sverige och pratar svenska med kunden. 

Men vad gäller diskussionen kring Repository, Command, Controller eller andra pattern namn så tycker jag att de ska vara på engelska. De är ju egen-namn som bara känns krystat att översätta. 

Vem översätter Internet till "det stora världsomspännande nätverket" (eller vad det skulle bli på engelska)? Kanske om vi bott på Island där alla ord har nya, egna namn på Isländska (dator = tölva (sammansättning av tal och völva (spåkvinna)), från wikipedia ;))

Keep it simple - använd etablerade begrepp där de finns. Det är ju dessutom en av idéerna bakom patterns; att vi snabb ska kunna utbyta stora mängder information om den lösning vi har byggt. 

/Marcus

www.marcusoft.net

Marcus Hammarberg

marcus...@gmail.com

http://www.marcusoft.net

[Jonas Lindström]

I en industrikoncern som vill hålla reda på sina fabriker kan det ju
bli riktigt rolig med FabrikFactory eller med hårddraget UL
FabrikFabrik :) Eller vad sägs om OrderLagerLager? Ursäkta kunde inte
hålla mig... ;)

Allvarligt talat så bildar jag nog helst klubb med Dan Bergh Johnsson
och behåller de engelska orden för patterns. Läs gärna hans artikel om
UL, den innehåller riktig vettiga riktlinjer, tycker jag.

[Jimmy]

Jag tror jag skrev lite för lite i mitt förra inlägg i denna tråden så
jag tänkte jag lägger till några rader idag.
:-)

Jag har inget emot engelska namn på patterns, absolut inte. Det jag
menade var snarare att jag tenderar att minska användning av pattern i
mina klassnamn (och andra namn som domänexperten tenderar att
exponeras för). Jag tycker helt enkelt inte heller det tillför något,
det är oftast uppenbart ändå. Därav att jag exemplifierade med att
väldigt få har med ValueObject i sina namn t ex. Den namnsättningsstil
jag har testat lite på sistone vad gäller just repositories är att
namnsätta i pluralis, t ex så här:

verkstäder.HämtaAllaI(växjö)
eller
verkstäderna.HämtaAllaI(växjö)

/Jimmy

[Fredrik Klintebäck]

Den funkar ju rätt bra, snyggt.

Nollplural blir lite lurigt men kör man med bestämd form kommer man runt det (Avtal - Avtalena)

 

2010/1/18 Jimmy <Jimmy....@jnsk.se>

[Jonas Lindström]

Det var som... Har aldrig tänkt på att använda bestämd form.
Nollplural har alltid gäckat mig, stört mig som attan på det, tack för
tipset!

On 18 Jan, 22:33, Fredrik Klintebäck <fredrik.klinteb...@gmail.com>
wrote:

> Den funkar ju rätt bra, snyggt.
> Nollplural blir lite lurigt men kör man med bestämd form kommer man runt det
> (Avtal - Avtalena)
>

> 2010/1/18 Jimmy <Jimmy.Nils...@jnsk.se>