Ubiquitous Language - w jakim stopniu stosujecie?

0

Czytam sobie Implementing DDD Vaughna Vernona. Autor stawia tam podział na strategic DDD (Ubiquitous Language, Core/ Supporting/ Generic Domain, Bounded Context, Context Map) i tactical DDD (Entity, Value Object, Aggregate, Domain Event, Repository, itd). Strategic DDD jest tą ważniejszą częścią DDD, a tactical DDD (bez strategic DDD) określa jako DDD-Lite, które samo w sobie daje niewiele zysku.

Strategic DDD w dużej mierze opiera się o Ubiquitous Language. To UL steruje podziałem na BC oraz komunikacją w zespole, zarówno między samymi programistami, jak i między programistami, a np ekspertami domenowymi, a nawet słownictwem używanym w interfejsie użytkownika czy API serwisów. Szerokie używanie UL wydaje mi się jednak nierealistyczne, bo trzeba nauczyć wszystkich zaangażowanych w projekt (programistów, menedżerów, ekspertów dziedzinowych, wsparcie produkcji, testerów, itd) by używali innego słownictwa (Ubiquitous Language) w zależności od omawianej części systemu (Bounded Context). Stąd w praktyce podział na Bounded Contexts i powiązane z nimi wyspecjalizowane Ubiquitous Languages będzie prawdopodobnie widoczny tylko w kodzie i dokumentacji stworzonej przez programistów, a nie w dokumentacji i poleceniach od zarządu czy ekspertów domenowych.

Jak zmieniła się wasza komunikacja z resztą zespołu (czyli programistami oraz innymi zaangażowanymi w projekt jak zarządem, ekspertami domenowi, wsparciem, testerami, itd) po wprowadzeniu DDD? Używacie wyspecjalizowanych Ubiquitous Languages w zależności od Bounded Contextów?

0

To nie do końca o to chodzi. Rzecz po prostu w tym że Custmer w jednym kontekście- mam na myśli rzeczywisty kontekst a nie "sztuczny" w kodzie- może oznaczać Payer w innym. Oba będą odnosiły się do tej samej fizycznej osoby, a więc posiadały te same ID oraz jakieś właściwości, np. Name, Surname. W związku z tym, jeśli w danym kontekście używa się konkretnej nomenklatury to przenosimy to do kodu a nie stosujemy globalnego bytu Customer. Tak więc ubiquitous language to coś co ma wypłynąć naturalnie w toku rozwoju oprogramowania i współpracy z ekspertami domenowymi, a nie coś co odgórnie narzucamy i wprowadzamy sztucznie.

0

Bardziej chodzi o odwrotny przypadek. Nie gdy jedno pojęcie jest pod kilkoma nazwami tylko gdy jedna nazwa może oznaczać kilka pojęć. Np account (vs user), product czy (w branży finansowej) security.

Ponadto rozmowy z ekspertami domenowymi mogą zmienić (np ujednolicić) język którym się posługują. Jak podaje Vaughn Vernon w http://www.informit.com/articles/article.aspx?p=1944876&seqNum=4 :

The Business Value of Using DDD
2. A Refined, Precise Definition and Understanding Is Developed
The business may actually come to understand itself and its mission better than before. I have heard others state that the Ubiquitous Language developed for the business's Core Domain has found its way into marketing materials. Certainly it should be incorporated in vision documents and mission statements.
As the model is refined over time, the business develops a deep understanding that can serve as an analysis tool. Details surface out of the minds of your domain experts as you are challenged by one another and shaped by technical team partners. These details can help your business analyze the value of the current and future direction, both strategic and tactical.
3. Domain Experts Contribute to Software Design
There is business value when the organization grows a deeper understanding of the core business. Domain experts don't always agree on concepts and terminology. Sometimes the differences are fostered by different experiences from outside before joining the organization. Sometimes it happens from the divergent paths required by each expert within the same organization. Yet when bringing them together to a DDD effort, the domain experts gain consensus among themselves. This fortifies the effort and the organization as a whole.

0

Bardziej chodzi o odwrotny przypadek. Nie gdy jedno pojęcie jest pod kilkoma nazwami tylko gdy jedna nazwa może oznaczać kilka pojęć.

Tak, skoro ta sama nazwa pasuje w kilku kontekstach to się jej używa.

Ponadto rozmowy z ekspertami domenowymi mogą zmienić (np ujednolicić) język którym się posługują.

Również tak.

Odpowiadając na pytanie z pierwszego postu- tak, używam w pracy UL. Z naciskiem na to że jest to coś co przychodzi naturalnie a nie wpychane na siłę.

0

Tak, skoro ta sama nazwa pasuje w kilku kontekstach to się jej używa.

W takim razie eksperci domenowi muszą być świadomi bounded contextów, które wypracowaliście. No chyba, że przyjmujecie postawę Conformist, a nie Partnership i dopasowujecie się bez zająknięcia do niejawnego podziału na konteksty wynikłego ze słownictwa ekspertów domenowych.

Z naciskiem na to że jest to coś co przychodzi naturalnie a nie wpychane na siłę.

Co to znaczy wpychane na siłę? Czy czyste DDD takie jak jest przedstawione w książkach Evansa czy Vernona to wciskanie UL na siłę? I co to znaczy naturalnie? Bez angażowania ekspertów domenowych w ustalanie spójnego słownictwa?

Odpowiadając na pytanie z pierwszego postu- tak, używam w pracy UL.

Pytanie było otwarte, a nie tak lub nie :]

Jak zmieniła się wasza komunikacja z resztą zespołu (czyli programistami oraz innymi zaangażowanymi w projekt jak zarządem, ekspertami domenowi, wsparciem, testerami, itd) po wprowadzeniu DDD?
Używacie wyspecjalizowanych Ubiquitous Languages w zależności od Bounded Contextów?

0

Dodam swoją perspektywę. Dołączyłem do projektu, gdzie już bylo stosowane DDD i UL bylo pilnowane. Sytuacja była taka, że był to mały, startujący projekt z jednym klientem i było fajnie, bo wszyscy posługiwali się tym samym językiem i bylo to pilnowane. Potem dochodzili nowi klienci i było wciąż OK - wewnątrz zespołu wszyscy posługiwali się UL, klienci mieli różne potrzeby i w różny sposób korzystali z produktu, my caly czas staraliśmy się uczyć klientów UL i go pilnować, jeżeli była potrzeba porozmawiać o jakimś ficzerze czy czymkolwiek. Często zdarzały się sytuacje gdzie, ktoś nie korzystał z tych samych terminologii, ale jeżeli nasz kontakt był mały to nie był to żaden problem, bo zespół cały czas komunikował się w ten sam sposób i nie było sensu wykładać tego ludziom. Wewnątrz zespołu był to duży plus, bo tak pojedyncze terminy jak i całe zwroty znaczyły to samo dla każdego, co ułatwiało komunikację werbalną, a także np. czytanie cudzych testów czy kodu. W przypadku kolejnego produktu wyglądalo to bardzo podobnie - pierwsze ficzery były uzgadniane z pierwszym klientem, który do tej pory kuma UL (w większości), więc wspólny język, bardzo fajnie, natomiast każdy kolejny klient wchodził w ten 'świat', gdzie zastawał określoną terminologię i się w miare dostosowywał, ale my nie naciskaliśmy bo wewnątrz wszyscy porozumiewali sie jednym językiem. Nie było natomiast zbyt wielu wieloznacznych określen, takich typowo ksiązkowych gdzie klient może oznaczać pasażera w 1 BC, a w drugim jakiś podmiot gospodarczy.

0

Jak tylko można, to korzystamy. Przy czym użycie UL z punktu widzenia zespołu wymaga dwóch rzeczy:

  1. Ludzie muszą chcieć nauczyć się pojęć domenowych do poziomu zrozumienia konsekwencji wymiany jednego na inne np. kredyt, a pożyczka.
  2. Zespół musi być w miarę stabilny personalnie, bo koszty wdrożenia nowych osób w UL bywają wyższe niż wdrożenia w kod.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.