DSL PROJEKTANTA

W tym artykule zajmę się zagadnieniem nazywania obiektów w procesie implementacji rozwiązania, które uważam za jeden z kluczowych umiejętności, tych najtrudniejszych, gdy projektujemy nową funkcjonalność.

DSL – teoria i praktyka

Domain Specific Language (DSL) można tłumaczyć jako język specyficzny dla danej dziedziny. DSL składa się więc z pojęć, sformułowań i słów kluczowych, które razem tworzą kompletny zbiór. W różnych dziedzinach życia mogą występować specyficzne dla nich zbiory słów.

Można tu przytoczyć dziedzinę prawniczą jako jeden z wielu przykładów, która posiada własny DSL. Słowa takie jak: sąd, sędzia, proces sądowy, apelacja, wyrok, adwokat, prokurator, kasacja, odwołanie itp. są słowami kluczowymi, które tworzą DSL.

Wyżej wymienione pojęcia są kreowane, by agregować i opisywać odpowiednio procesy, ich uczestników oraz wyniki procesów. Na podstawie tak sformułowanych pojęć nie trudno byłoby stworzyć model domeny i zaimplementować określoną logikę biznesową.

Inaczej sytuacja wygląda, gdy domena rozwiązania nie istnieje.  W takim przypadku powinna zostać wykreowana. Można to wykonać poprzez zdobycie wiedzy o rozwiązaniu, poznanie procesów biznesowych, zidentyfikowanie poszczególnych elementów domeny rozwiązania i zbudować z tego zbioru własny język domeny DSL, który zostanie wykorzystany w procesie produkcji rozwiązania.

DSL a nazywanie artefaktów

Nazywanie artefaktów jest rzeczywiście dosyć trudne szczególnie wówczas, gdy chcemy, aby nazwa klasy czy metody zajmowała właściwe miejsce ze względu na swoją odpowiedzialność w całym rozwiązaniu. Często robimy to intuicyjnie lub inspirowani przez bardziej doświadczonych od nas nie zdając sobie sprawy z jakich podstaw to wynika i robimy to dobrze. Jednak zdarzają się również przypadki, gdzie nazwane klasy, funkcje czy metody mają niewiele wspólnego z tym co realizują. Nie musze chyba pisać, jak czyta się taki kod… a przecież tworzenie oprogramowania w dzisiejszych czasach to prawie zawsze praca zbiorowa i każdy członek zespołu developerów musi sprawnie czytać kod, rozumiejąc „od pierwszego wejrzenia” na poziomie ogólnym proces biznesowy, jego przepływy i zależności. Słowem rozumując na pewnym poziomie abstrakcji, kod powinno czytać się niemal jak książkę opowiadającą pewną historię (proces) złożoną z epizodów (mniejszych procesów) i wydarzeń (zdarzeń).

Można tego dokonać między innymi, gdy nazwane w kodzie źródłowym artefakty odpowiadają zdefiniowanemu wcześniej zestawowi słów kluczowych używanych naturalnie przez użytkowników lub odbiorców rozwiązania nazywanych dalej skrótowo DSL.

Użycie DSL w procesie produkcji oprogramowania.

Doświadczone zespoły produkcyjne posługują się DSL w sposób świadomy, wiedząc, że odgrywa kluczową rolę w podczas komunikacji. Określone pojęcia użyte np. podczas rozmowy wywołują u odbiorcy dokładnie te same skojarzenia co u nadawcy, co powoduje, że finalnie rozwiązanie będzie spójne i zgodne z założeniami. Dzięki takiemu podejściu komunikat wykorzystujący wcześniej ustalony DSL jest w stanie dotrzeć bez zniekształceń przez wszystkie etapy wytwarzania oprogramowania, począwszy od zlecającego poprzez opiekuna produktu, analityka, projektanta, programistę, testera i w drugą stronę. Jak widać, w niektórych przypadkach, węzłów komunikacji może być naprawdę wiele i nietrudno o wypaczenie. Dlatego niektóre metody wytwarzania wyróżniają rolę tzw. eksperta domenowego, który ma za zadanie zarządzać DSL dla rozwiązania. Rola ta została szerzej opisana w książce Erica Evansa „Domain Driven Design”, którą polecam. W praktyce rolę eksperta domenowego pełni ktoś w roli analityka biznesowego, czasami jest to projektant lub rola, która jest połączeniem wyżej wymienionych.