Domain Driven Design pt.1- DSL

Po przeczytaniu wpisu na blogu Cyśka stwierdziłem, że jednak świadomość rozumienia istoty modelu w świecie PHP wymaga poprawy i stąd ten artykuł. Opiszę w nim jeden ze sposobów tworzenia warstwy modelu, a dokładnie metodologię DDD. Dla pobieżnego zapoznania się z tematem polecam Wikipedię, natomiast ja będę starał się rozwinąć ten temat tutaj i pokazać go na przykładach, czego większości opisów brakuje.

Jeszcze słowem wstępu powiem, że metodologia DDD nie tylko mówi jak zaprojektować warstwę modelu, oprócz tego odnosi się również do prowadzenia samego projektu informatycznego ukierunkowanego na stworzenie gotowego produktu. Metodologia DDD w kwestii prowadzenia projektu mówi, że model domeny nigdy nie jest ukończony, jego powstawanie wiążę się ze stałym kontaktem z klientem. Rozmawiając z klientem porozumiewamy się z nim w języku domeny czyli w terminologii danego zagadnienia. Wielu z Was pewnie łapię się za głowę i pyta – po co to wszystko ? Przecież żeby postawić stronę wizytówkę nie potrzeba żadnej magicznej terminologii i kontaktów z klientem… I macie racje, generalnie metodologie DDD stosuje się do projektów o skomplikowanej logice, czyli generalnie do aplikacji dedykowanych. Nikomu raczej bym jej nie polecał stricte do budowania CMS-a, chociaż można wykorzystać pewne jej elementy.

Wracając do języka domeny. Zdefiniujmy sobie przykładowy problem, załóżmy, że mamy do wykonania dedykowana aplikację hurtowni internetowej w której będziemy obsługiwać klientów korporacyjnych. Rozmawiając z klientem będziemy używali takich terminów z języka domeny jak: kontrahent, faktura, księgowanie, przedstawiciel handlowy, towar, oferta handlowa, zamówienie. W tradycyjnym podejściu z pewnością kontrahenta i przedstawiciela handlowego nazwalibyśmy Userem, towar produktem, zamówienie koszykiem a oferta handlowa była by jakimś tam rabatem. Rozmawiając z klientem w sposób tradycyjny w przypadku jakichkolwiek błędów w naszej aplikacji spotykamy się z sytuacją, gdy obie strony mówią niby o tym samym ale zupełnie co innego mają na myśli, co generuje dodatkowe błędy. Miałem (nie) przyjemność pracować przy projekcie, w którym właśnie nastąpiło rozminięcie się terminologii pomiędzy klientem a wykonawcą aplikacji i powiem Wam, że nie życzę nikomu tego doświadczenia.

Pewnie u części z Was w tym momencie zaświeciła się nad głową żarówka i wpadliście na z pozoru świetny pomysł „ale co nas obchodzi język domeny, rolą projekt managera jest to, żeby nam przełożył język domeny na coś zrozumiałe dla nas programistów”. W metodologii DDD, kładzie się nacisk na to, by używać języka domeny również w kodzie (nazwy metod, klas, pól, zmiennych), dzięki temu gdy następują jakieś zmiany w modelowanym przez nas zagadnieniu (a jest to proces ciągły i nieskończony) możemy odnaleźć w naszych klasach metody, które dokładnie odpowiadają zachowaniu się modelowanej domeny. Efektem ubocznym takiego podejścia jest to, że programista uczestniczący w projekcie prowadzonym w terminologii DDD staje się stopniowo specjalistą w danej dziedzinie, a przynajmniej zaczyna się w niej orientować.

Podsumowując, w tym wpisie dowiedzieliśmy się czym jest Domain Specific Language i jaką rolę odgrywa w budowaniu modelu oraz jakie konsekwencje niesie ze sobą jego używanie bądź nie używanie. W drugiej części serii postaram się zaprezentować jak przełożyć DSL na konkretny kod.

Mam nadzieje, że zainteresowała Was ta tematyka i liczę na Wasze pytania i komentarze 😉

EDIT:

Alan Gabriel Bem w komentarzu słusznie zauważył dwie istotne rzeczy. Pierwszą rzeczą jest kwestia klienta, celowo ją uogólniłem do postaci abstrakcyjnej osoby która wie co aplikacja ma robić. Natomiast w terminologii i metodologii DDD ten abstrakcyjny klient nazywa się ekspertem dziedziny. Są to osoba, lub osoby, które są specjalistami w swoich dziedzinach i od których uzyskujemy informacje o tym jak ma działać ta część aplikacji, która dotyczy wykonywanych przez nich obowiązków. Wracając do przykładu z hurtownią internetową, takimi specjalistami mogą być na przykład księgowa, od której dostaniemy informacje o fakturowaniu, czy przedstawiciel handlowy od którego dostaniemy informacje o tym jak powinna wyglądać oferta handlowa czy zamówienie.

Drugą rzeczą jest bariera językowa, metodologia DDD zaleca aby terminy z DSL występowały również w kodzie jako nazwy metod, klas, pól i ich zmiennych. Nie jest to problemem jeżeli mamy do czynienia z klientem anglojęzycznym, natomiast jak je nazywać gdy robimy coś dla polskiej firmy ? Czy należy Usera nazwać Użytkownikiem, a fakture oznaczyć jako Invoice ? A może jakieś rozwiązanie mieszane w rodzaju metod w stylu getUżytkownik() ? Nie jest to jeszcze duży problem, gdy modelowany przez nas problem da się łatwo przełożyć na język angielski i terminy w obu językach tłumaczą się bez wieloznaczności. Natomiast co z bardziej specyficznymi dziedzinami w których nie ma dokładnych tłumaczeń ? Na to pytanie postaram się odpowiedzieć w dalszych częściach cyklu…

  1. Alan Gabriel Bem pisze:

    1. Uogólniłeś klienta… wspomnij o roli eksperta dziedziny w DDD.

    Osobiście w DDL nienawidzę bariery językowej, która mimo wszystko jest w naszym kraju wciąż obecna…. bo jak tu programować po polsku :) Wiem, że nie ma z tym problemu, gdy klientem jest międzynarodowy moloch, ale klientów się nie wybiera.

  2. Alan Gabriel Bem pisze:

    Wojtku, można prosić o wstawienie jakiegoś pluginu do mailowego powiadamiania o nowych komentarzach?

  3. Wojciech Soczyński pisze:

    Poszukam coś w internecie, natomiast zawsze możesz subskrybować kanał RSS z komentarzami :)

  4. Alan Gabriel Bem pisze:

    Dzięki :)

  5. Hubert pisze:

    odnośnie tych komentarzy – http://blog.wsoczynski.pl/comments/feed/ 😉

    co do DDD kilka ciekawych artów na ten temat można znaleźć na http://blog.fedecarg.com/

  6. Wojciech Soczyński pisze:

    Dodałem też te powiadomienia, na dole pod komentarzem powinien być checkbox. Co do bloga frederica to go znam, szkoda, że jak na razie nie pisze nic więcej. Co do mojego cyklu o ddd chce bardziej przybliżyć tą metodologię od strony modelowania, mniej od konkretnej implementacji w jakimś środowisku ormów czy zenda, chociaż kod też będzie :)

  7. cysiaczek pisze:

    Moim zdaniem dobrze zauważyłeś, że wymaga poprawy :(
    Problematyczne jest w przypadku stron www i aplikacji webowych projektowanie modeli, które powinny jednocześnie szybko się inicjować oraz być odpowiednio złożone. To po prostu odrobinę inaczej niż w aplikacjach, gdzie program jest ciągle w określonym stanie. Dla porównania, uruchamiaj .exe i wybieraj jego polecenia poprzez parametry. To niemal dokładne odwzorowanie działania aplikacji w PHP (noo, powiedzmy tam, gdzie mamy Front Controller). Proste rozwiązania, z pominięciem warstwy usług (ja to uważam w pewnym sensie za Model, ale nie mam wykształcenia więc wybacz 😉 ) zazwyczaj dobrze sprawdzają się tam, gdzie coś (jedno-dwa) skomplikowanego po prostu „się musi zrobić”… a reszta to jakieś proste listingi, podglądy, pakowanie których w Services to jedynie nadmiarowe opakowywanie kodu, którego i tak nigdy później nie wykorzystać inaczej niż metodą copy&paste&doSomeMess.
    Tak wygląda większość oprogramowania, wszędzie na tym rynku. Wszystko dlatego, że opracowanie odpowiednio ogólnego i jednocześnie niezbyt szczegółowego komponentu to dużo wyższy koszt. Pluginy do Symfony również nie spełniają warunków dobrego komponentu. Może symfony2 (bundles) i Doctrine2 coś zmienią (W Doctrine 2 w końcu odseparowane Encje o czym piszesz :).

    Pozdrawiam

  8. obserwator pisze:

    chyba wiem o jakim projekcie i o ktorej PM mowisz :) jesli masz racje to bron swojego zdania bo faktem jest ze projekt byl skomplikowany.

  1. […] Opublikował Wojciech Soczyński dnia lip 28, 2010 in php, programowanie | Subskrybuj W poprzednim artykule z serii Domain Driven Design przedstawiłem pole zastosowań metodologii DDD, jej otoczkę […]

  2. […] przykładowej aplikacji napisanej w metodyce DDD. W ciągu tych trzech miesięcy jakie minęły od pierwszego wpisu wielokrotnie podejmowałem próby napisania czegoś. Jednak nigdy nie było ani jakiegoś […]

  3. […] przykładowej aplikacji napisanej w metodyce DDD. W ciągu tych trzech miesięcy jakie minęły od pierwszego wpisu wielokrotnie podejmowałem próby napisania czegoś. Jednak nigdy nie było ani jakiegoś […]

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.