Ubiquitous language, czyli dlaczego nie lubię Kubusia Puchatka

Muszę przyznać, że w ogóle nie lubię angielskich słów w naszej branży. Wiem, że często nie ma w języku polskim dobrych odpowiedników (najlepszym dla mnie przykładem takiego koślawego tłumaczenia jest „kwerenda” – słowo tak sztuczne, jak tylko można sobie to wyobrazić). No ale jakoś nie lubię, bo potem wychodzi tak, że „deplojujemy na uata po merdżu pulrikłesta”.

Ale do rzeczy – w DDD jednym z najważniejszych elementów jest ubiquitous language. I tu jestem bezradny. Najlepszym tłumaczeniem jakie udało mi się znaleźć jest „wszędobylski język”, a to kojarzy mi się jakoś pokrętnie z Tygryskiem z Kubusia Puchatka. I cała powaga tematu pryska, a ja widzę skaczącego, pasiastego kocura, który śmiga do góry na sprężystym ogonie. No więc pogodziłem się ze sformułowaniem angielskim, choć to cudo nie wiadomo jak czytać, łatwo się pomylić w pisaniu i w ogóle jest jakieś takie dziwne. Żeby więc uniknąć zbędnych pomyłek i konfuzji od teraz będę pisał UL.

A czym jest UL? To po prostu wspólny język, którym posługujemy się, rozmawiając z biznesem o jego potrzebach. Język jest „wszędobylski”, bo musi pojawić się wszędzie: przy pisaniu specyfikacji, modelu, ustalaniu szczegółów, w rozmowach programistów, wreszcie w kodzie. Jeśli ustalimy, że słowo „Client” oznacza jakiegoś konkretnego aktora w naszych przypadkach użycia, to musimy trzymać się tych ustaleń zawsze (z małymi zastrzeżeniami dotyczącymi ograniczonego kontekstu, ale o tym kiedy indziej).

Tu pojawiają się dwa zasadnicze problemy: jeden mały, drugi duży.

Po pierwsze: niespójność słownika biznesowego. Oczywistym źródłem UL jest klient (a w zasadzie ekspert domenowy). Może on używać różnych terminów oznaczających to samo albo nie używać w ogóle konkretnych słów na opisanie jakiegoś pojęcia czy procesu. Różne mogą być tego powody, ale tak po prostu bywa. Przykładowo klient przychodni może być również określany mianem „pacjenta” – w zależności od kontekstu. Jeśli umawiamy się, że plan dnia w naszej aplikacji do obsługi przychodni nazywa się „Schedule” to tak musi być wszędzie. Ważną – i relatywnie trudną do ogarnięcia – konsekwencją tego jest fakt, że także biznes musi używać UL. I tu mogą pojawić się schody, bo biznes to nie tylko ekspert domenowy, ale zwykle cała armia różnych innych osób, niezainteresowanych wcale tym, żeby nam się wygodniej pracowało.

Po drugie: niespójność używanych języków. Miałem okazję pracować przy projekcie klienta z jednego z krajów nieużywających języka angielskiego. Pojawiło się tam kilka pojęć, których sens był zupełnie inny i musiał być odwzorowany w logice aplikacji. Ku mojemu zdziwieniu, przy próbie ustalenia słownika UL ujawnił się zasadniczy problem. Wszystkie te pojęcia tłumaczone dosłownie na angielski dawały w efekcie jedno i to samo słowo! I co tu zrobić? Programista Polak, klient – powiedzmy – Niemiec, UL najlepiej jakby był po angielsku, bo jak brzmiałaby metoda getNachrichten() albo updateVorname()?

To ogromny kłopot, ale nawet to jest do przeskoczenia. Zrobiliśmy tak:

1. Po pierwsze usiedliśmy z ekspertem domenowym i zebraliśmy wszystkie terminy funkcjonujące w języku klienta, a istotne z punktu widzenia aplikacji.

2. Opracowaliśmy słownik tłumaczeń tych terminów na angielski – każde tłumaczenie było uzgadniane z osobami, które potencjalnie mogły być zainteresowane samą aplikacją. Słownik został jeszcze na końcu potwierdzony i umówiliśmy się, że rozumiemy wszystkie zawarte w nim terminy.

3. Słownik – a właściwie jego angielska „strona” była podstawą opisu, specyfikacji, modelu, bazy danych, kodu itp. Klienci w rozmowach z nami posługiwali się czasami terminami nieangielskimi (po prostu to się zdarza z przyzwyczajenia), ale dzięki słownikowi zawsze wiedzieliśmy, o czym dyskutujemy.

4. Po pewnym czasie wszyscy stali się nieco dwujęzyczni – rozumieliśmy zarówno pojęcia z UL jak i źródła tych pojęć w języku klienta. Oczywiście podstawą był zawsze język angielski.

Powyższy schemat nie jest optymalny, zdaję sobie z tego sprawę. Ale wydaje mi się, że – w większości przypadków takich wielojęzycznych konfiguracji – jedyny możliwy.

Reklamy

3 uwagi do wpisu “Ubiquitous language, czyli dlaczego nie lubię Kubusia Puchatka

  1. No i koniec, zepsułeś mi mózg. Teraz już zawsze na myśl o ubiquitous language będę wydział Tygryska 😦

    A z samym UL faktycznie może być problem. Ostatnio rozmawiałem z Wojtkiem Malarą o sytuacji prostszej – polski zespół i polski klient. Niby nie powinno być problemu, ale przecież z przyzwyczajenia kod zwykliśmy pisać po angielsku. I doszliśmy do wniosku, że może najlepiej byłoby kod pisać jednak po polsku. Wtedy nic się nie straci podczas tłumaczenia. Jak myślisz?

    I tak patrząc na na powyższy przykład, może jednak warto wprowadzić getNachrichten() itp? Wtedy też nie ma miejsca na dwuznaczność. A słownik zostaje, żeby ułatwić rozumienie kodu. Sam już nie wiem

    Polubienie

    1. Powiem tak: z naszego, polskiego punktu widzenia może to być dobry pomysł. Ale – hipotetycznie – nasz projekt może trafić w ręce – dajmy na to – francuskiego zespołu. I co oni wtedy zrobią z naszym getKlienci() albo getUprawnieniaDlaKlienta()?

      Wiesz, miałem kiedyś projekt napisany przez zespół z Hiszpanii. Do dziś mi się śnią te getVersionRecintoForAcontecimiento(). Dramat. Nie sposób wejść w kod bez szkolenia z hiszpańskiego.

      Dlatego ja osobiście jestem organicznie uczulony na jakiekolwiek wtręty w kodzie w innym języku niż angielski. Ale chyba każdy ma swój punkt widzenia – wcale nie uważam, że moje podejście jest jedyne właściwe.

      Polubienie

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s