Wszechobecny język - konflikt między poprawnością a użytecznością


10

Zasadniczą częścią Domain Driven Design jest konsekwentne stosowanie wszechobecnego języka w całym systemie - w rozmowach, kodzie, schemacie bazy danych, interfejsie użytkownika, testach itp.

Jestem zaangażowany w projekt, w którym istnieje już dobrze ugruntowany język domen, zdefiniowany przez międzynarodową organizację normalizacyjną.

Jednak praca, którą wykonujemy, dotyczy publicznej witryny internetowej, a „prawidłowe” warunki dla domeny niekoniecznie są takie, jak opinia publiczna zazwyczaj ich używa i rozumie.

Kompromis, którego obecnie używamy, polega na stosowaniu „oficjalnych” warunków wszędzie, z wyjątkiem naszych kryteriów akceptacji, które odnoszą się do komponentów interfejsu użytkownika, w których używamy nieformalnych nazw.

Czy to wydaje się rozsądnym podejściem?


Czy możesz podać przykład? Mógłbym wtedy udzielić bardziej szczegółowej odpowiedzi. Czy musisz je dla nich ograniczać, czy też kolidują terminy o zupełnie innych znaczeniach? Czy w ogóle byłoby możliwe znalezienie wspólnej płaszczyzny między nieformalnymi warunkami a językiem domeny?
Falcon

1
Minęło trochę czasu, odkąd przeczytałem tę część książki Evansa, ale myślałem, że wszechobecny język powinien być używany z ekspertem w tej dziedzinie? Z pewnością nie oczekiwałbym, że użytkownik zrozumie całą terminologię eksperta w dziedzinie, więc przedstawię użytkownikowi tylko to, co nazwaliście nieformalnymi nazwami.
Kaleb Pederson

Odpowiedzi:


7

Tak, to wydaje się rozsądne. Jeśli docelowi odbiorcy nie rozumieją warunków Twojego języka lub źle je interpretują, pierwszeństwo ma użyteczność dla użytkownika końcowego.

Program lub treść, której nie rozumie typowy użytkownik, ma niewielką wartość. Co więcej, jeśli chcesz tylko przedstawić im uproszczoną wierzchołek góry lodowej, ponieważ nie są i nigdy nie będą ekspertami w dziedzinie.

Zwykle, kiedy mówisz o domenie podczas programowania, wszyscy rozumieją język, ponieważ jest on dokładny, a wszyscy ludzie są w domenie. Ale jeśli wartość biznesowa powstaje w wyniku komunikacji treści z osobami z zewnątrz domeny, zrób to tak prosto, jak to możliwe. Używaj sformułowań i języków, które są najmniej zrozumiane, i używaj ich w interfejsie użytkownika.

Zachowaj dokładny język w kodzie i do komunikowania się z osobami zainteresowanymi domeną. Są to ludzie, którzy mają specyfikacje i którzy są kluczowymi użytkownikami aplikacji, z którymi omawiasz logiczne szczegóły biznesowe. W rzadkim przypadku, w którym naprawdę omawiasz większość logicznych szczegółów biznesowych z użytkownikami, którzy nie mają pojęcia o domenie i nie musisz zagłębiać się w nią, a następnie włączyć ich język do języka domeny, biorąc pod uwagę, że mieć wspólny, jednoznaczny język w ogóle (co prawdopodobnie nie jest prawdą).

Ale upewnij się, że deweloperzy frontonu wiedzą o twoich nieformalnych warunkach i odpowiadających im warunkach domeny.


1

Myślę, że najłatwiejszym sposobem na to byłoby narysowanie linii dokładnie tam, gdzie byś ją narysował, gdybyś przedstawiał interfejs w zupełnie innym języku.

Gdyby Twoi użytkownicy końcowi chcieli zobaczyć rzeczy w sanskrycie, w jaki sposób można zlikwidować różnicę między interfejsem użytkownika a kodem (i inną komunikacją wewnętrzną).


Dobrze powiedziane. Wskazuje to na „Humpty-Dumpty Problem”: słowa nie są tylko substytucją, odnoszą się do rzeczy, o których ludzie wiedzą o nich niezależnie od słów i ich użycia. Zwierzęta rozumieją na przykład pojęcie „temperatury”. Rozłączamy się ze słowami, gdy są one tylko symbolami pojęć. Pojęcia są ważne.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.