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
Niniejszym otwieram cykl postów związanych z rozkminianiem architektury wytwarzania oprogramowania o nazwie DDD => Domain-Driven Design. Jest to temat jaki od pewnego czasu dręczy mnie, i chcę rozwinąć swoje zdolności w tym konkretnym obszarze.
W tym celu zaopatrzyłem się w dwie pozycje:
 |
Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym. Eric Evans. |
 |
DDD dla architektów oprogramowania, Vaughn Vernon. |
Czym jest Domain-Driven Design?
Jest to podejście do budowania aplikacji, w którym zaczynamy od stworzenia tak zwanego Modelu Domeny (eng. Domain Model). Sam model nie jest niczym innym jak wyodrębnionym głównym zachowaniem aplikacji jaki ma zostać zaimplementowany.
Aplikacja zbudowana jest z wielu elementów:
- interfejs użytkownika,
- obsługa wejść/wyjść,
- obsługa bazy danych,
- inne usługi wspierające tworzenie aplikacji.
Model Domeny/Dziedziny (eng. Domain Model) nie zawiera tego bagażu, to czysta implementacja wartości (wartość biznesowa) jaką ma dawać aplikacja. Stworzona w sposób niezależny i łatwa do przetestowania.
W celu jej implementacji programista musi rozumieć co jest najważniejszą wartością w oprogramowaniu jakie ma wykonać. Dlatego musi kontaktować się z osobą posiadającą największą wiedzę na temat funkcjonalności tworzonej aplikacji. Osoba taka określana jest jako Ekspert Domenowy (eng. Domain Expert),może to być np. klient.
Często pojawia się problem z wymianą informacji (niejednokrotnie się z nim zetknąłem). Dotyczy problemów językowych występujących w komunikacji pomiędzy programistą, a ekspertem domenowym. Osoby te zazwyczaj wywodzą się z innych środowisk i pojęcia jakimi operują nie są zrozumiałem lub znaczą coś zupełnie innego dla strony przeciwnej.
Rozwiązaniem problemu jest stosowanie tak zwanego języka wszechobecnego (eng. Ubiquitous Language). Zawierającego wspólnie wypracowane pojęcia dzięki, którym zarówno ekspert domenowy zrozumie programistę jak i odwrotnie.
Jest to technika trudna, wymagająca w implementacji odpowiedniego projektowania i nakładająca na programistę dodatkowy narzut pracy związany z klepaniem kodu.
Do budowy aplikacji opartej o Domain-Driven Design wykorzystać można wielowarstwową architekturę aplikacji. W ten sposób model domenowy zostanie wyodrębniony do własnej warstwy.
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…
Następny artykuł: Domain-Driven Design - Język Wszechobecny.
