DDD - kiedy należy o tym pomyśleć

Witam,
kiedy należy pomyśleć o podejściu Domain Driven Design w necie jest pełno materiałów o technikach DDD ale nie wiele kiedy tak naprawdę należy to stosować....tak można znaleźć, że do skompilowanych systemów, ale co to znaczy....raczej oczewkiwałbym informacji jakie są problemy i co rozwiązuje DDD np

Raz rozmawiałem z gościem który uzasadniał wprowadzenie DDD tak: mieliśmy anemiczny model (encje, geter, setery) więc wprowadziliśmy DDD - no dobra ale co wam to dało, w czym wam przeszkadzał anemiczny model....
**
Czy ktoś z was robił projekt w techince DDD i jest w stanie powiedzieć co to przyniosło...**

Po pierwszym komentarzu również mogę powiedzieć, że raczej chodzi mi o korzyści dla programistów mających całkowitą wiedzę merytoryczną

Mogę się mylić ale DDD polega na tym że projekt utrzymuje specyficzne wytyczne określane mianem wiedzy domenowej - dzięki czemu w projekcie może brać udział osoba nietechniczna posiadająca wiedzę domenową (dla niej nie liczą się gettery/settery), osoba ta w jednoznaczny sposób jest w stanie przekazać reszcie zespołu informacje potrzebne do zaprogramowania danych funkcjonalności. Wg mnie DDD rozwiązuje problemy komunikacyjne z klientem, niweluje w jakimś stopniu problemy z tym że klient chciał X a dostał Y. DDD może też spowodować że proces wytwarzania kodu będzie bardziej rygorystyczny (dużo większy nacisk na SOLID). Jak przeszliście z anemicznego modelu do DDD? Ile to trwało?

ja stwierdzam, ze jak cos jest za bardzo trudne do nauki i zbyt zagmatwane to szkoda czasu sie tego uczyc.
a tak jest z DDD.
jest anemiczna encja to jest spoko bo widac czarno na bialym dokladnie ze ta klasa mapowana jest na ta tabelke i jest schludnie czysto i czytelnie
a nie w DDD encja z milionem metod.
to sie stosuje do pewnego poziomu i rozumiem ze na encji mozna dac metode np. public void disable() { isActive = false; } ale
nie ze oni wszystkie biznesowe rzeczy chca robic w encji i robic jakies cuda na kiju.
KISS

tymbardziej ze java, jpa, spring itd... narzucaja techniczne ograniczenia wykonywania DDD

Na moje to DDD sluzy do rozwiazywania skomplikowanych i zlozonych problemow przy duzych projektach, gdzie rowniez dziedzina jest trudna jak i wyznaczenie bounded context. Chyba trudno sie tego nauczyc poza praktyka w takim projekcie.

Nie podchodzilbym do tego, ze nie warto i w sposob lekcewazacy.

Biblia DDD to książka Erica Evansa & co. Tam właśnie pisze, kiedy należy to stosować. Jest to szereg zasad, z których można sobie coś powybierać. Naczelną jest wyizolowanie dziedziny, czyli sedna merytorycznego projektu. W pewnym sensie warto to stosować w każdym projekcie, a przynajmniej w każdej chwili się zastanawiać, czy wg DDD byłoby tak samo. Bez tej cegły nie ma co się brać za DDD, a nawet jak się nie chce brać, to i tak warto przeczytać. Oczywiście odpowiada wyczerpująco na Twoje pytania.

No i Eric Evans mówi też talki na Youtube - (można oglądać z przyśpieszoną prędkością, bo ten pan ma dość powolny/zrelaksowany sposób mówienia). Polecam, bo można się dowiedzieć o co naprawdę chodzi w tym (Evans wydaje się dość pragmatycznie nastawiony do tematu, w odróżnieniu do zwolenników DDD*).

*zwolennicy DDD = ludzie, którzy robią cargo cult z DDD i myślą, że polega ono na komplikowaniu projektów albo stosowaniu na chybił trafił wzorców projektowych z książki. A tymczasem istotą DDD okazuje się być opracowywanie modelu domeny, czy coś w tym stylu - jak to się dowiedziałem z talka Erica Evansa - polecam fragment od 30:00 bo wtedy zaczyna mówić o modelu.

Poza tym jak nie DDD to co? 3warstwowa z grubymi serwisamy i toną per type packages?

Z tego co ja zrozumialem to w DDD zamiast grubych serwisow robisz cienkie serwisy, ktore jedynie cos wywoluja a logika jest w domain objects.

Biay napisał(a):

Poza tym jak nie DDD to co? 3warstwowa z grubymi serwisamy i toną per type packages?

Z tego co ja zrozumialem to w DDD zamiast grubych serwisow robisz cienkie serwisy, ktore jedynie cos wywoluja a logika jest w domain objects.

SOA, jedyna słuszna architektura dla Spring/JEE.

Trzeźwy Kret napisał(a):

Biay napisał(a):

Poza tym jak nie DDD to co? 3warstwowa z grubymi serwisamy i toną per type packages?

Z tego co ja zrozumialem to w DDD zamiast grubych serwisow robisz cienkie serwisy, ktore jedynie cos wywoluja a logika jest w domain objects.

SOA, jedyna słuszna architektura dla Spring/JEE.

A od kiedy to wyklucza DDD?
Nie ma czegos takiego jak 'jedyna sluszna architektura'

Panowie mam wrażenie, że nie mieliście do czynienia z DDD w praktyce ** takie teoretyczne podstawy, książki, youtube to ja znam....chodzi mi o konkrety....
Teksty typu celem DDD jest wyizolowanie dziedziny są dla mnie słabe....po co to robisz? jaki miałeś problem z aktualnym stanem? co wprowadzenie DDD CI dało? Jakie problemy rozwiązało?

Robić coś dla sztuki jest trochę nieuzasadnione.....

Szczery napisał(a):

Panowie mam wrażenie, że nie mieliście do czynienia z DDD w praktyce ** takie teoretyczne podstawy, książki, youtube to ja znam....chodzi mi o konkrety....
Teksty typu celem DDD jest wyizolowanie dziedziny są dla mnie słabe....po co to robisz? jaki miałeś problem z aktualnym stanem? co wprowadzenie DDD CI dało? Jakie problemy rozwiązało?

Robić coś dla sztuki jest trochę nieuzasadnione.....

Sęk w tym, że DDD praktykowało niewiele firm. Chciałem się tego trochę poduczyć ale niestety nie widzę sensu uczyć się teorii...
Czekam aż znajdę się w takim projekcie mając jedynie jakieś tam podstawy. Do czegoś nieskomplikowanego nie widzę sensu używać.

Może kogoś z Allegro zapytaj, oni sobie chwalą.

Cz napisał(a):

Trzeźwy Kret napisał(a):

Biay napisał(a):

Poza tym jak nie DDD to co? 3warstwowa z grubymi serwisamy i toną per type packages?

Z tego co ja zrozumialem to w DDD zamiast grubych serwisow robisz cienkie serwisy, ktore jedynie cos wywoluja a logika jest w domain objects.

SOA, jedyna słuszna architektura dla Spring/JEE.

A od kiedy to wyklucza DDD?
Nie ma czegos takiego jak 'jedyna sluszna architektura'

Pytasz od kiedy SOA wyklucza DDD? Jak dla mnie to dwie zupełnie różne koncepcje. W jednej robimy gadające ze sobą serwisy, w drugiej gadające ze sobą obiekty dziedzinowe. W pierwszym przypadku mamy "full-power" kontenerów, w drugim to tracimy*.
Z drugiej strony fajne jest to że jak włączymy obiekty do sesji Hibernate to mogą one gadać między sobą i zmieniać swój stan, a na koniec zostanie on automatycznie zapisany, ale w praktyce chyba rzadko kiedy taka sytuacja ma miejsce :p

* No chyba że oddelegujemy interfejs biznesowy obiektu do serwisu i będziemy programować obiektowo tak jak się programuje obiektowo w C, czyli struktura sobie a funkcje sobie, np.:

@Entity
class Project{
 ...
}

@Service
class ProjectBusinesInterface{
   void projectBizMethA( Project project, args...){
          project.setAsdasd(..)
          project.setBjkabsdkja(..)
          ...
    }
   void projectBizMethB( Project project, args...){
          project.setBbnbnbn(..)
          ...
    }
}

projectService.projectBizMethA(project, args);
projectService.projectBizMethB(project, args);

albo jakoś tak

Panowie mam wrażenie, że nie mieliście do czynienia z DDD w praktyce takie teoretyczne podstawy, książki, youtube to ja znam....chodzi mi o konkrety

Ja zacząłem akurat od praktyki, gdzie musiałem wejść w istniejące projekty, i dopiero teraz łapię podstawy teoretyczne. Ale to jest tak, że teoria jest często bardziej rozsądna od tego, jak w praktyce jest to zaimplementowane. W praktyce widzisz po prostu masę kodu i nie łapiesz się co jest co (zakładając, że wchodzisz w istniejący duży projekt). W teorii masz wyjaśnienie czemu tak, a nie inaczej.

Oczywiście, praktyka jest ważna (sam zawsze to powtarzam), tym niemniej problem z DDD jest taki, że jest to pewna filozofia projektowania oprogramowania, którą można różnie interpretować, nie zawsze rozsądnie, i różnie można implementować to w praktyce (gdzie zamiast ładnego designu masz np. big ball of mud).

To tak jak z Agile - w manifeście Agile ładnie to wygląda, a w firmach Agile to zwykle waterfall inaczej nazwany.

jakie są problemy i co rozwiązuje DDD np

Jeśli nie wiesz jakie problemy rozwiązuje, to znaczy, że odpowiedź jest prosta: nie stosuj.

Np. jeśli nie wiesz, jakie problemy rozwiązuje proponowany w DDD ubiquitous language , to nie stosuj go (ew. zacznij jak nabierzesz doświadczenia zawodowego i zobaczysz, że większość problemów programisty bierze się z kiepskiej komunikacji z innymi ludźmi).

jeśli nie widzisz wartości w wydzielaniu logiki dziedziny, to nie wydzielaj (ew. zacznij jak nabierzesz doświadczenia i sparzysz się parę razy na fakcie, że jej nie wydzieliłeś)

DDD to żadna magia, tylko rzeczy do których ludzie sami by doszli mając odpowiednie doświadczenie - po prostu ktoś je zebrał w jedną spójną filozofię, opracował teorię i ponazywał elementy.

@brunatny Szczur jakoś wielu używa DDD właśnie z mikroserwisami.