Artykuł ten jest częścią serii artykułów na temat Domain-Driven Design.
Agenda
1. Wstęp.
2. Język Wszechobecny.
3. Izolacja przy pomocy warstw.
4. Podstawowe części składowe.
5. DDD i jego życie.
6. Nadejszła wiekopomna chwiła.
Wstęp
Odwiecznym problemem jaki napotykają na swojej drodze dwie ścierające się siły: zlecający i wykonawca, jest wzajemna komunikacji i zrozumienie. Problem narasta gdy obie persony obracają się w odseparowanych środowiskach. Przykładem takiej sytuacji jest klient (Ekspert Domenowy, eng. Domain Expert) definiujący wymagania aplikacji i wykonawca (np.: zespół programistów, programista).
Dobrym przykładem takiej sytuacji jest często komunikacja pomiędzy kobietą i mężczyzną wprowadzająca zamęt, poprzez niejednoznaczne rozumienie wypowiadanych słów.
Specyfika obszarów zainteresowania zawodowego obu osób przeważnie jest tak odległa, iż wzajemne zrozumienie/przekazanie specyfikacji produktu do wykonania skutkuje powstaniem wielu nieścisłości i zgrzytów. Obie osoby zazwyczaj rozmawiają z wykorzystaniem odmiennych zestawów definicji nie mających ze sobą zbyt wiele wspólnego.
Język Wszechobecny (eng. Ubiquitous Language)
Z pomocą przychodzi metoda wytwarzania oprogramowania Domain-Driven Design
Otóż nie jest to jedynie architektura. Zawiera w sobie wiele definicji co do kultury pracy w projekcie zarówno od strony definiującego/weryfikującego wymagania. a także ich realizatora.
Jednym z jej aspektów jest wykreowanie tak zwanego Języka Wszechobecnego (eng. Ubiquitous Language), zmieniającego sposób komunikacji pomiędzy osobą wymagającą, a realizującą. Wprowadza wspólnie ustalony zestaw słów/definicji w formie żargonu. Tym samym podnosi się jakość wzajemnej komunikacji poprzez zrozumienie istoty wymagań i problemów jakie zaistnieją w trakcie realizacji projektu.
Opracowanie słownictwa Języka Wszechobecnego poprzez wspólną analizę dziedziny i dojście do konsensusu nazewnictwa poszczególnych elementów, pozytywnie wpływa na współpracę i kulturę pracy w zespole.
Słownictwo języka wszechobecnego powinno bazować na Modelu Domeny (eng. Domain Model). Skutkuje to wykorzystaniem zdefiniowanych pojęć, w każdym aspekcie projektu. Od modelowania klas po dokumentację i komunikację dotyczącą projektu. Zespół powinien weryfikować wprowadzone pojęcia w celu eliminacji błędnych sformułowań. Dobrą praktyką jest wypowiadanie pojęć na głos, łatwiej będzie wówczas wyłapać dziwne sformułowania.
Język Wszechobecny (eng. Ubiquitous Language) jest ściśle związany z Modelem Domeny/Dziedziny (eng. Domain Model), dlatego wprowadzanie zmian w żargonie niesie ze sobą potrzebę zmiany modelu i odwrotnie
Projektując i budując aplikację często napotykamy na problemy związane z określeniem punktu wspólnego tematyki jakiej poruszał projekt. W pewnym sensie także nazewnictwo zostało narzucone przez przełożonych bądź w przeciwną stronę.
Nadmieniam, tutaj iż głoszę swój osobisty punkt widzenia i sposób prezentacji wiedzy. A jako że nie jestem nieomylny, to mogą i zapewne będą zdarzać się błędy…
Polecane książki
Wcześniejszy artykuł: Domain-Driven Design - Wstęp.
Następny artykuł: Domain-Driven Design - Izolacja przy pomocy warstw.
