Programowanie i język wszechobecny (DDD) w domenie innej niż angielska

Wiem, że są tu już pewne pytania, które są ściśle związane z tym tematem, ale żadne z nich nie przyjmuje Ubiquitous Language jako punktu wyjścia, więc myślę, że uzasadnia to pytanie.

Dla tych, którzy nie wiedzą: język wszechobecny to koncepcja zdefiniowania języka (zarówno w mowie, jak i piśmie), który jest w równym stopniu używany przez programistów i ekspertów domeny, aby uniknąć niespójności i niewłaściwej komunikacji z powodu problemów z tłumaczeniem i nieporozumień. Zobaczysz tę samą terminologię w kodzie, rozmowy między członkami zespołu, specyfikacje funkcjonalne i tak dalej.

Zastanawiałem się więc, jak radzić sobie z językiem wszechobecnym w domenach innych niż angielski.

Osobiście zdecydowanie wolę pisanie kodu programowania w języku angielskim całkowicie, w tym komentarze, ale oczywiście z wyłączeniem stałych i zasobów.

Jednak w domenie innej niż angielska jestem zmuszony podjąć decyzję, aby:

1. Napisz kod odzwierciedlający wszechobecny język w języku naturalnym domeny.
2. Przetłumacz język wszechobecny na angielski i przestań komunikować się w naturalnym języku domeny.
3. Zdefiniuj tabelę, która określa, w jaki sposób język wszechobecny tłumaczy się na angielski.

Oto kilka moich przemyśleń opartych na tych opcjach:

1) Mam silną niechęć do kodu mieszanego, tzn. Kodowania przy użyciu nazw typów / członków / zmiennych itp., Które nie są językiem angielskim. Większość języków programowania w dużym stopniu „oddycha” angielskim, a większość literatury technicznej, nazwy wzorów itp. Są również w języku angielskim. Dlatego w większości przypadków po prostu nie ma możliwości pisania kodu całkowicie w języku innym niż angielski, więc i tak kończysz na mieszanych językach.

2) Zmusi to ekspertów z dziedziny do rozpoczęcia myślenia i mówienia w angielskim odpowiedniku UL, co prawdopodobnie nie przyjdzie im naturalnie, a zatem znacznie utrudni komunikację.

3) W tym przypadku programiści komunikują się ze specjalistami ds. Domeny w swoim ojczystym języku, podczas gdy programiści komunikują się ze sobą w języku angielskim, a co najważniejsze, piszą kod przy użyciu angielskiego tłumaczenia UL.

Jestem pewien, że nie chcę iść na pierwszą opcję i myślę, że opcja 3 jest znacznie lepsza niż opcja 2. Co myślisz? Czy brakuje mi innych opcji?

AKTUALIZACJA

Dzisiaj, około rok później, po codziennym rozwiązywaniu tego problemu, muszę powiedzieć, że opcja 3 zadziałała dla mnie całkiem dobrze.

Nie było to tak nudne, jak się początkowo obawiałem, a tłumaczenie w czasie rzeczywistym podczas rozmowy z klientem również nie stanowiło problemu.

Na podstawie mojego doświadczenia uznałem również, że są to następujące zalety.

• Tłumaczenie UL powoduje, że zwracasz większą uwagę na definiowanie UL, a nawet samej domeny, szczególnie gdy nie wiesz, jak przetłumaczyć termin i musisz zacząć przeglądać słowniki itp. To spowodowało, że ponownie przemyślałem decyzje dotyczące modelowania domen kilka razy.
• Pomaga pogłębić znajomość języka angielskiego.
• Oczywiście, twój kod jest o wiele przyjemniejszy dla oka, niż oszałamiająca obsceniczność.

Często napotykałem ten problem i moim zdaniem odpowiedź brzmi: „nie ma jednej odpowiedzi ważnej dla wszystkich scenariuszy”.

Pamiętaj jednak, że język wszechobecny nie jest celem samym w sobie. Jest to narzędzie do usprawnienia komunikacji między zespołem i ekspertami domen oraz do wymuszenia spójności koncepcyjnej wdrożonego modelu w kodzie, testach i rozmowach.

Jeśli umiesz mówić jednoznacznie w języku UL, jesteś na dobrej drodze. Jeśli ty i twoi rówieśnicy nieustannie tłumaczymy z kodu na rozmowę lub od pomysłu do pomysłu, prawdopodobnie jesteś na dobrej drodze.

W praktyce nie wszystkie domeny są równe, ani eksperci w dziedzinie. Niektóre domeny i tak mają wiele angielskiej terminologii (na przykład domeny oparte na technologii) i rozsądne wydaje się wybranie opcji w pełni angielskiej. Jednak niektóre kultury mogą wpływać na ten wybór (przychodzi na myśl francuski), a rozpowszechnianie angielskiej terminologii różni się w zależności od kraju. W niektórych innych domenach (prawnych, żeby wymienić), nie ma sposobu na przetłumaczenie niektórych terminów. Lub tłumaczenie utrudniłoby Domain Expert śledzenie rozmowy.

Ogólnie jesteśmy bardziej zainteresowani tym, co ma do powiedzenia ekspert domeny. Dlatego chcemy ułatwić im to. W przeciwnym razie mogliby po prostu wziąć udział w lekcji UML i przeczytać nasze diagramy (to był żart). Zatem jedyną prawdziwą rekomendacją jest: „zwróć uwagę na zachowanie eksperta domeny”, jeśli są zaangażowani w rozmowę i rozmowa przebiega gładko, prawdopodobnie jesteś na dobrej drodze, zachowaj ten język. Może to wymagać trochę dodatkowej pracy w zespole, ale nie ma sprawy. Jako programiści jesteśmy nieco wyszkoleni do uczenia się słów o określonym znaczeniu w kontekście.

O dziwo, temu pytaniu zawsze towarzyszy założenie, że cały kod musi mówić w jednym języku. To też może być kwestionowane. Nie jestem ojczystym językiem angielskim, a znajomość języka obcego nie jest płaska: mój mózg idzie szybko, gdy mówię o nazwisku , nazwisku , samochodzie itp., Brakuje niektórych szczegółów, gdy mówię o kodzie pocztowym , zwalnia, gdy mówię o pożyczce i zdecydowanie pyta dla uspokajającego wyjaśnienia przy mówieniu o hipotece .

Ponownie wybierz najlepszą kombinację, która sprawi, że kluczowa konwersacja przebiegnie i zapewni najwyższą ilość informacji i opinii od eksperta domeny.

Zwykle uważam pewne słowa techniczne za neutralne językowo, nawet jeśli jest tłumaczenie na inny język.

Na przykład, kiedy mówię o kodowaniu w języku niemieckim, wciąż używam angielskiego słownictwa technicznego, jakby to były niemieckie słowa, nawet jeśli istnieje niemiecki odpowiednik.

W twoim przypadku zrobiłbym coś przeciwnego. Zaimportuj niektóre słowa techniczne z języka ojczystego na angielski, tak jak słowa obce były importowane od stuleci. Niech gramatycznie zachowują się jak angielskie słowa. Na początku wydaje się to dziwne, ale przyzwyczaisz się do tego.

Zgadzam się z komentarzem angielskim dotyczącym większości języków programowania , który zawsze staje się problemem przy wielojęzycznych pracach rozwojowych

Normalnie miałbym UL w języku twojego zespołu programistycznego

W przeszłości robiliśmy nowe słowa, które lepiej wyrażają tematy związane z domeną. W projekcie francusko-angielskim wymyślone słowa były w większości oparte na języku angielskim, ale o francuskim smaku (nie za trudne, ponieważ wiele angielskich słów to francuski), ale może to dotyczyć dowolnej kombinacji językowej

na przykład

„Bois ilości”

W języku angielskim jest „Ilość drewna” lub „ilość drewna”, w języku francuskim „quantité de bois”, więc jest wystarczająco blisko dla obu mówców. Powinno to zmniejszyć liczbę nowych słów, których każdy mówca musi się nauczyć

Jak duża jest twoja domena UL? To staje się problemem. Jeśli zawiera mniej niż 100 fraz kluczowych, możesz użyć hybrydowego języka stylistycznego, jeśli większy, trzymałbym się dominującego języka programistów, ponieważ zwykle muszą się z nim intensywniej posługiwać

Opublikuj słownik wiki / tezaurus, aby każdy mógł się do niego odwoływać w razie potrzeby, więc nie ma wymówek dla zrozumienia

Niedawno pracowałem nad projektem DDD w Szwajcarii, gdzie domeną były podatki (w szczególności VAT i inny rodzaj podatku ... który nie jest łatwy do przetłumaczenia na angielski ...).

Wybrali pierwszą opcję: UL w języku niemieckim, także w kodzie w języku niemieckim.

Zanim pracowałem nad tym projektem, miałem dokładnie taką samą niechęć jak ty w przypadku kodu mieszanego. (Nadal) lubię mieć wszystko po angielsku, chociaż nie jestem rodzimym językiem angielskim. Nie jestem też native speakerem niemieckiego. Kiedy zacząłem odkrywać bazę kodów, byłem przerażony.

Po roku pracy nad tym projektem muszę przyznać, że uważam, że w tym przypadku była to właściwa decyzja (moglibyśmy również użyć francuskiego lub włoskiego, innych oficjalnych języków szwajcarskich, ale większość aktorów w tym projekcie była rodzimym językiem niemieckim głośniki).

Wiele szczegółowych warunków domeny naprawdę nie można było w znaczący sposób przetłumaczyć na angielski. I tak musiałem nauczyć się niemieckiego, aby komunikować się z resztą zespołu. Byłoby bałagan, gdybyś musiał nauczyć się również angielskich tłumaczeń, które i tak wymyśliłby z powietrza.

Myślę, że to naprawdę zależy od domeny. Niektóre domeny będą bardzo trudne do przetłumaczenia na angielski i nie będzie to miało większego sensu.

Prawdopodobnie zależy to również od języka ojczystego. Niemiecki to język, w którym można komponować słowa mniej więcej w ten sam sposób, a zwłaszcza w tej samej kolejności, co w języku angielskim. Na przykład deklaracja podatkowa byłaby Steuerdeklaration . Nie szokująco inaczej.

Na przykład nie wiem, jak nazwałbym równoważną nazwę klasy w języku francuskim, gdyby naturalnym terminem było „déclaration d'impôts”, z odwrotną kolejnością i dodatkowym przyimkiem pośrodku ... prosty przykład. Byłbym bardzo zainteresowany, gdyby ktoś miał doświadczenie w tego rodzaju nazywaniu w językach łacińskich (francuski, hiszpański, włoski, portugalski ...)!

Kolejnym wyzwaniem były formy liczby mnogiej, które w języku niemieckim czasami trudno odróżnić od liczby pojedynczej (podczas gdy w języku angielskim prawie zawsze ma s na końcu).

Podkreślone znaki były OK, ponieważ w języku niemieckim wszystkie mają nieakcentowany odpowiednik ( ü -> ue i tak dalej). To kolejny punkt, w którym Francuzi byliby bardziej problematyczni ...