Język wszędobylski (Ubiquitous Language) to jedno z prostszych do wdrożenia narzędzi strategicznego Domain-Driven Design. W tym artykule przybliżę Ci pojęcie języka wszędobylskiego, jego rolę oraz znaczenie. Dowiesz się również, jaki wpływ na wykorzystanie języka wszędobylskiego ma pojawienie się nowego aktora, czyli AI.

Czym jest język wszędobylski?

We wstępie już padło stwierdzenie, że język wszędobylski (lub też język wszechobecny) to jedno z narzędzi strategicznego DDD. Strategiczne narzędzia DDD służą do analizy domen biznesowych i budowania ich zrozumienia przez stakeholderów. Strategiczne DDD odpowiada na pytania: jaki system tworzymy oraz w jakim celu go tworzymy.

Ubiquitous Language jest związany z konkretnym Bounded Contextem. Jeśli system składa się z kilku Bounded Contextów, każdy z nich może mieć własny model domenowy i Ubiquitous Language. Bounded Context to wzorzec definiujący granicę, w ramach której obowiązuje określony model domenowy. Ten sam termin może mieć różne znaczenia w różnych Bounded Contextach. Na przykład Customer może w kontekście sprzedaży oznaczać osobę dokonującą zakupu, a w kontekście obsługi klienta osobę zgłaszającą problem.

Język wszędobylski to wspólny język służący do opisywania modelu domenowego w ramach danego Bounded Contextu, wypracowany wraz ze stakeholderami (lub też interesariuszami) zaangażowanymi w pracę nad danym kontekstem. Wykorzystanie wspólnego języka znacznie ogranicza konieczność dokonywania translacji z języka domenowego na język wykorzystywany w dokumentacji oraz kodzie i vice versa. Translacja, oprócz tego, że jest czasochłonna, może powodować utratę części informacji.

Wdrażając język wszędobylski, deklarujemy, że w ramach komunikacji dotyczącej danego Bounded Contextu osoby zaangażowane w pracę nad nim będą posługiwać się wspólnym językiem. W szczególności:

• Eksperci domenowi/dziedzinowi – osoby posiadające biznesową wiedzę o dziedzinie, dla której tworzony jest system. Na przykład w systemie dla księgowości może to być księgowy lub księgowa.
• Architekci i deweloperzy – osoby projektujące i tworzące system, wykorzystujące język wszędobylski w kodzie, testach, dokumentacji i modelach.
• Analitycy i product ownerzy – osoby definiujące cele, user stories i wymagania zrozumiałe dla pozostałych stakeholderów.

Należy podkreślić, że język wszędobylski to język domenowy. Opisujemy nim pojęcia, zachowania i reguły domenowe. Należy dążyć do tego, by język był prosty i naturalny w codziennym użyciu. Swobodne posługiwanie się językiem wszędobylskim wymaga od stakeholderów niebędących ekspertami domenowymi choćby podstawowego zrozumienia domeny. Wiedza domenowa nie tylko pozwala efektywniej komunikować się w projekcie, ale również pozwala uwzględniać ją w projektowaniu i implementacji rozwiązania.

W kształtowaniu języka domenowego powinniśmy unikać technicznych pojęć oraz szczegółów związanych z implementacją systemu w kodzie. Język wszędobylski nie jest dobrym miejscem do stosowania technicznego żargonu, nazw wzorców, pojęć architektonicznych, nawiązań do implementacji czy struktur bazodanowych.

Język wszędobylski, podobnie jak języki używane w codziennej komunikacji jest żywy. Oznacza to, że nie jest ustalany raz i już się nie zmienia. Wraz ze zdobywaniem wiedzy o domenie język wszędobylski może ewoluować. Również zmiany w samej domenie mogą przyczyniać się do ewolucji języka wszędobylskiego.

Spójność i jednoznaczność

W codziennej komunikacji rzadko przywiązujemy wagę do precyzji i spójności słownictwa. Mówiąc o samochodzie, jeśli powiemy „auto”, „fura”, „bryka” itp., każdy zrozumie, o czym mówimy. W przypadku słów wieloznacznych również jesteśmy w stanie wywnioskować z kontekstu, w jakim znaczeniu zostały użyte. Słysząc „złamałem klucz w zamku”, raczej nikt nie pomyśli, że chodzi o budynek.

Załóżmy, że system wymaga klucza licencyjnego (License Key) dla aplikacji klienckiej oraz klucza API (API Key) do wysyłania zapytań bezpośrednio do backendu. Używając w komunikacji po prostu słowa Key, wprowadzamy chaos i zamieszanie. Oba klucze odnoszą się do dwóch różnych pojęć w systemie; mają różne reguły walidacyjne i odpowiedzialności. Pozornie niewielka niejednoznaczność może długofalowo spowodować, że różni stakeholderzy będą mieli odmienny obraz systemu, co może przekładać się np. na błędne decyzje dotyczące rozwoju produktu czy zrozumienia jego problemów.

Analogicznie wygląda sytuacja, gdy opisujemy ten sam byt w systemie różnymi pojęciami. W podanym przykładzie z API Key moglibyśmy spotkać się z alternatywnymi pojęciami: Auth, Token, Auth Token, Key, API Secret. Pierwszym problemem wynikającym z wykorzystania wielu pojęć jest ryzyko, że dane pojęcie może opisywać coś innego. Token może reprezentować zupełnie inny byt niż API Secret czy API Key. Nawet jeżeli obecnie w systemie nie ma takiego bytu, to jego pojawienie się może całkowicie zaburzyć znaczenie wcześniejszych ustaleń i dokumentów. Kolejnym problemem jest różny poziom zrozumienia domeny przez stakeholderów. Dla niektórych stakeholderów może to nie być oczywiste, że opisujemy ten sam byt w systemie różnymi pojęciami.

Nie potrzebujesz wdrażać pełnego DDD!

Jedną z największych zalet Domain-Driven Design jest to, że nie trzeba od razu wdrażać pełnego zakresu pojęć, narzędzi i wzorców, by usprawnić naszą pracę.

Co więcej, w przypadku języka wszędobylskiego, jak i wielu innych narzędzi z DDD, nie musimy tego formalnie deklarować: „Od dziś komunikujemy się językiem wszędobylskim!” Wdrażanie Ubiquitous Language można zacząć od drobnych usprawnień. Na sam początek można po prostu zwracać większą uwagę na wykorzystywane pojęcia czy słownictwo. Możemy zacząć pilnować spójności w kodzie, dokumentacji, opisach tasków czy komunikacji z innymi stakeholderami.

Jeśli nie czujemy się na tyle pewnie, by publicznie zaadresować temat wykorzystania języka wszędobylskiego w komunikacji, możemy zastosować metodę małych kroków i stopniowo wprowadzać go do codziennej pracy nad projektem. Możemy wykorzystywać pytania precyzujące, np. „Mówiąc Token, miałeś na myśli X czy Y?”. Inną metodę, zgodną z ideą małych kroków, zauważam czasami w rozmowach z native speakerami języków dla mnie obcych. Jeśli popełnię jakiś błąd, rozmówca często nie poprawia mnie bezpośrednio. Zamiast tego formułuje swoją wypowiedź tak, by użyć poprawnej wersji błędnie użytego przeze mnie zwrotu czy wyrażenia.

AI – nowy konsument języka wszędobylskiego

Do rozmów między biznesem a zespołem deweloperskim dołączył nowy aktor – LLM-y. Stał się częścią zarówno pracy biznesu, jak i zespołu deweloperskiego. Zarówno deweloperzy i architekci, jak i analitycy oraz eksperci dziedzinowi wykorzystują narzędzia AI do pracy nad swoimi zadaniami.

Gwałtowne zwiększenie tempa dostarczania kodu i dokumentów powoduje, że konsekwentne trzymanie się języka wszędobylskiego jest jeszcze ważniejsze. Wyłapywanie odstępstw od języka wszędobylskiego w treściach generowanych przez LLM-y oraz podczas komunikacji z nimi jest moim zdaniem krytycznie ważne. Odstępstwa mogą sprawić, że LLM-y znacząco zwiększą tempo propagowania takich błędnych terminów. Przy obecnym tempie generowania slopu treści naprawienie wszystkich nieścisłości po czasie może oznaczać sporo dodatkowej pracy oraz potencjalne konflikty czy niedopowiedzenia.

Kluczowe jest upewnienie się, że LLM poprawnie stosuje język wszędobylski obowiązujący w danym kontekście. LLM może znać znaczenie poszczególnych terminów z danych treningowych. Jednak nie zna naszego konkretnego Ubiquitous Language ani znaczenia tych pojęć w naszym kontekście. Pracując z LLM-ami, należy dostarczyć im jednoznaczny opis pojęć i reguł domenowych.

Najprostszym sposobem na dostarczenie tej wiedzy LLM-om jest spisanie jej i dołączenie do kontekstu, np. w postaci pliku Markdown. W środowiskach takich jak Claude Code, Codex czy Cursor możemy przechowywać taką dokumentację w osobnym pliku i wskazać ją agentowi w pliku AGENTS.md czy CLAUDE.md. Plik ten nie powinien być zwykłym słownikiem pojęć, ale definiować również reguły i zależności związane z poszczególnymi pojęciami domenowymi. Taka dokumentacja może być przydatna nie tylko dla LLM-ów, ale również dla ludzi. Odpowiednio przygotowana może pomóc w promowaniu i przyswajaniu języka wszędobylskiego przez nowych i obecnych stakeholderów. Mając jasno zdefiniowany język wszędobylski, możemy również wykorzystać LLM-y do wykrywania nieścisłości i odstępstw.

Warto mieć z tyłu głowy, że LLM-y, podobnie jak ludzie, nie są bezbłędne. Niedeterministyczna natura LLM-ów sprawia, że nawet w przypadku idealnie zdefiniowanego i opisanego języka wszędobylskiego istnieje ryzyko, że LLM nie będzie go stosował w 100% poprawnie.

Podsumowanie

Domain-Driven Design zawsze kojarzyło mi się z narzędziami przeznaczonymi do pracy przy tych „dużych i poważnych” projektach. Jednak DDD pozwala na wykorzystanie wybranych narzędzi, a język wszędobylski nawet w małym projekcie może realnie zwiększyć komfort pracy. Nie musimy pracować nad ogromnym systemem, by dostrzec korzyści z wykorzystania wspólnego, spójnego i logicznego języka.

Źródła i materiały dodatkowe

• Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy – Vlad Khononov s. 24
• Domain-Driven Design – Eric Evans s. 52
• Great quotes for the concept of Ubiquitous Language
• Speaking Ubiquitous Language – Tomasz Ducin
• bITconf 2019 – [Kamil Grzybek] Czysty model domenowy: Domain-Driven Design taktycznie i praktycznie
• „Software Fundamentals Matter More Than Ever” — Matt Pocock
• Programming and Ubiquitous Language (DDD) in a non-English domain
• DDD: What is the scope of the ubiquitous language? Is it domain or bounded context?

Zaobserwuj mnie w mediach społecznościowych!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!

Chcesz docenić moją pracę? Postaw mi kawę!