Czy używacie w pracy DDD?

0

Jak to jest w rzeczywistości? Nie ukrywam, że temat jest efektem mojej frustracji wynikającej z niemożności pojęcia tegoż.

2

Dupa Driven Debugging? Codziennie, kto by sie debugerem poslugiwal.

0

A którego DDD? ;)

10

Z DDD jest jak z prawdziwym komunizmem. Niektórzy próbują wprowadzać, potem się nie udaje i mówią że to nie był prawdziwy... i próbują znów :)

0

@Shalom: A jak Ty piszesz aplikacje? Logike umieszczasz w encjach czy w serwisach aplikacyjnych?

2

A to jedno drugie wyklucza? Robie tak żeby miało to ręce i nogi. Przecież zupełnie inną logikę umieszcza się w bezstanowych serwisach (np. stukanie w jakieś endpointy czy repozytoria) a zupełnie inną w obiektach domenowych. To jest trochę jakbyś pytał czy jem rano czy wieczorem ;]

0

Chodzi mi o sama logike biznesowa. Chyba zgodnie z DDD cala ma byc w domenie.

0

Nie używam ale planuję poczytać o tym.
Kiedyś używałem Double Density Disk ale chyba nie o to chodziło.
https://acronyms.thefreedictionary.com/DDD

1

A czym jest domena? Ja się staram mieć rozgraniczoną logikę i całe sprawy zewnętrzne (baza danych, endpointy itp), co znaczy, że da się samą logikę odpalić niezależnie od wszystkiego (w pamięci) i póki co to działa

0
nobody01 napisał(a):

Chyba zgodnie z DDD cala ma byc w domenie.

Chyba nie za bardzo rozumiesz czym jest domena.

0

A czym jest?

2

Uczę się stale DDD, chcę się więcej uczyć i mam zamiar nadal nie używać.

5

Domena to w dużym skrócie "dziedzina" lub "zadanie". Przykładowo jak masz aplikację magazynową to masz parę domen:

  • pracownicy i wszystko związane z tym kto kim jest
  • "autoryzacja" czyli stwierdzanie, że dana osoba jest tym kim jest
  • magazyn
  • etc.

Więc mówienie, że "cała logika powinna być w domenie" jest głupie, bo logika zawsze jest w domenie. DDD to nie specjalnie jest podejście do pisania aplikacji co do jej projektowania i sposobu rozmawiania z klientem, to jak to potem zostanie zaimplementowane (CQRS, mikroserwisy, event bus, etc.) nie ma najmniejszego znaczenia, bo z punktu widzenia DDD to szczegół implementacyjny. Same domeny będą różne w zależności od tego czym ma się zajmować aplikacja i bardzo często mogą się zmieniać w czasie rozwoju aplikacji. Całość sprowadza się dokładnie do tego co napisał @Shalom, czyli by całość miała ręce i nogi we w miarę logicznie wydzielonych częściach, które odpowiadają "ideom" klienta (czyli właśnie domenie).

10

Z DDD jest trochę jak z Agile. Idea była dobra, zresztą taka sama jak idea OOP -> żeby modelować dziedzinę problemu i na niej operować, tak żeby mieć wspólny jezyk z klientem. Bo klienta interesuje że np. przetwarzasz zamówienie a nie że masz rekord w bazie danych albo stukasz gdzieś w restowe endpointy.
Ale niestety dorwali się do tego jacyś filozofowie i postanowili z tego zrobić jakaś religię z dogmatami i świętymi pismami.

Analogicznie jak z Agile -> idea była dobra, ale potem dorwali się do tego dziwni ludzie i nagle mamy Scrumy, które z Agile nie maja nic wspólnego, bo niby było Individuals and interactions over processes and tools a nagle masz 17 spotkań scrumowych dziennie i nie możesz się wymigać bo proces jest najważniejszy ;)

4

Co prawda nigdy nie używałem DDD, ale sporo o tym czytałem i widzę 2 bariery:

  1. Pseudo-religijna otoczka, nakręcana przez znanych szkoleniowców, którzy często propagują myślenie "kup nasze szkolenie, bo to jest bardzo trudne i sam nie dasz sobie rady". Nie mam nic przeciwko szkoleniom, sam bym w takim chętnie wziął udział (jakby firma zapłaciła ofc), ale taki marketing nie pomaga. Dodatkowo powagi dodają specyficzne nazwy typu "blue book" czy "red book" :)

  2. Nie wiem czy to tylko moje odczucie, ale sporo mówi się o technikach DDD, ale mało o implementacji i np. ja czuję się kompletnie zagubiony, jeśli miałbym coś faktycznie napisać od zera. Konkretne tematy typu realna implementacja persystencji, eventów czy bounded context jakoś się mało rzucają w oczy, zamiast tego mamy "produkt i zamówienie"...

1

Dajcie już sobie spokój, ile można te bzdury pisać.

Typu nie umiem, nie znam. To znaczy, że to religia i że to głupie....

No przecież czytanie książek o programowaniu w ogóle jest głupie, jak się ma te wspaniałe forum. :D

Książki o DDD potrafią znacząco podnieść skill'a oraz jakość wytwarzanego oprogramowania, jak i masa innych książek.

3

Nie podjęliśmy się jeszcze w pracy projektu faktycznie prowadzonego wg DDD, bo to wymaga m.in. zaangażowania klienta, a klienci wolą mieć analityków, którzy przychodzą od userów, rzucają na stół "tego chce lud" i idą po następne skrzynki z user stories.
Ale ogólnie nasz zespół mocno bada temat, są książki, firma płaci za szkolenia i konferencje, ludzie sami szukają czegoś więcej w tym temacie. I mimo, że projektu "zgodnego z DDD" jako takiego nie ma to widać, że pewna kultura pracy czy podejście do problemów się zmieniły i ludzie bardziej domenowo myślą.

A co do tego offtopicu o religii, szkoleniach itp. to moim zdaniem wynika to z prostej rzeczy - ludzie nie lubią nieprecyzyjnych zasad. Stąd ktoś wziął ideę agile i zamienił na "17-spotkaniową postać normalną Scruma", w DDD mamy całe scenariusze spotkań i mapowania "karteczka na tablicy -> klasa", tak samo jak przy RODO od razu pojawiało się milion pytań o to jak DOKŁADNIE ma wyglądać strona/umowa/treść ostrzeżenia/maile mimo, że początkowo ideą było właśnie to żeby tylko wskazać kierunek. A potem pewna grupa znalazła niszę na rynku i wyznacza leniwym ludziom konkretną listę punków do odznaczenia po której będą mogli wpisać na stronie, że ich firma ma SCRUMa/DDD/WTF/ABC.

0

W moim projekcie zaczeliśmy robic DDD. Niestety brak doświadczenia jak to zrobić porządnie i ciągłe zmiany struktury aplikacji ze strony klienta oraz kompletny brak przemyślenia potrzeb sprawił że raczej po pół roku developmentu DDD więcej utrudnia nz pomaga. A szkoda bo nadal samo podejście mi się podoba i jest kilka aspektów które mają sens nawet w projektach bez DDD.

1

W DDD podoba mi się jasny podział na aplikację, infrastrukturę i domenę (logikę biznesową). Korzystam, jeżeli zespoł chce korzystać i każdy mniej więcej ogarnia o co chodzi, jak ktoś się wyłamie to faktycznie może to sprawiać więcej problemów - gdy zacznie umieszczać kod nie tam gdzie trzeba.

Nigdy nie robiłem właściwego DDD (poza warsztatami), gdzie razem z biznesem (u mnie to zazwyczaj byli programiści którzy znali domenę) ogarniacie jak wszystko ma wyglądać (głównie nazewnictwo).

1

Cel DDD jest bardzo zbliżony do celu Agile, mianowicie przybliżenie biznesu jak najbliżej kodu. Zamiast tworzyć dodatkowe modele biznesowe z których powstaje kod, to kod ma być tym modelem, pomostem pomiędzy biznesem/analitykami a programistami, modelem nad którym mogą pracować obie strony ze zrozumieniem. Także żeby mieć DDD jedyne co jest potrzebne poza zaangażowaną stroną biznesową, to dzielenie problemów na mniejsze konteksty i używanie wszechobecnego języka domenowego. Reszta o czym się mówi w kontekście DDD to są szczegóły implementacyjne, których wcale stosować nie musimy jeśli nam to nie pasuje do rozwiązania konkretnego problemu. Możemy nie mieć warstw, nie mieć eventów, mieć anemiczny model domenowy i ciągle robić DDD :)

0
neves napisał(a):

Cel DDD jest bardzo zbliżony do celu Agile, mianowicie przybliżenie biznesu jak najbliżej kodu. Zamiast tworzyć dodatkowe modele biznesowe z których powstaje kod, to kod ma być tym modelem, pomostem pomiędzy biznesem/analitykami a programistami, modelem nad którym mogą pracować obie strony ze zrozumieniem. Także żeby mieć DDD jedyne co jest potrzebne poza zaangażowaną stroną biznesową, to dzielenie problemów na mniejsze konteksty i używanie wszechobecnego języka domenowego. Reszta o czym się mówi w kontekście DDD to są szczegóły implementacyjne, których wcale stosować nie musimy jeśli nam to nie pasuje do rozwiązania konkretnego problemu. Możemy nie mieć warstw, nie mieć eventów, mieć anemiczny model domenowy i ciągle robić DDD :)

Brzmi rozsądnie tylko trochę bez sensu z tym dzieleniem na konteskty.

Przecież mogę mieć model w jednym kontekście, ale bazować na czymś innym co jest opisane w książce.

Ja radzę w ogóle zapomnieć o czymś takim jak "to jest DDD, Robić DDD" jak chcecie "robić DDD" to sobie weźcie taki sam biznes jak w książce i sobie zróbcie DDD....

W DDD podoba mi się jasny podział na aplikację, infrastrukturę i domenę (logikę biznesową). Korzystam, jeżeli zespoł chce korzystać i każdy mniej więcej ogarnia o co chodzi, jak ktoś się wyłamie to faktycznie może to sprawiać więcej problemów - gdy zacznie umieszczać kod nie tam gdzie trzeba.

Nigdy nie robiłem właściwego DDD (poza warsztatami), gdzie razem z biznesem (u mnie to zazwyczaj byli programiści którzy znali domenę) ogarniacie jak wszystko ma wyglądać (głównie nazewnictwo).

Zawiodę cię, ta architektura warstwowa była już wcześniej opisana w innych książkach jak większość wzorców.

0

trochę bez sensu z tym dzieleniem na konteksty

Czemu? Przykładowo jak piszemy aplikację dla szpitala, to konteksty wychodzą "automatycznie":

  • karta pacjenta
  • księgowość
  • recepcja
  • "gabinet"
  • magazyn
  • apteka
  • etc.

Każda z tych części posługuje się innym językiem i wymaga innych rzeczy, więc naturalnie jest wydzielić je od siebie i pracować z nimi jako osobnymi domenami. Nie tylko tak będzie to łatwiejsze, to jeszcze będzie łatwiej rozmawiać z biznesem.

1
hauleth napisał(a):

trochę bez sensu z tym dzieleniem na konteksty

Czemu? Przykładowo jak piszemy aplikację dla szpitala, to konteksty wychodzą "automatycznie":

  • karta pacjenta
  • księgowość
  • recepcja
  • "gabinet"
  • magazyn
  • apteka
  • etc.

Każda z tych części posługuje się innym językiem i wymaga innych rzeczy, więc naturalnie jest wydzielić je od siebie i pracować z nimi jako osobnymi domenami. Nie tylko tak będzie to łatwiejsze, to jeszcze będzie łatwiej rozmawiać z biznesem.

Ja tylko wskazuje na to, że ja na siłę nie muszę wymyślać kontekstów tam, gdzie ich nie ma tylko dlatego, że tak było w książce.

0

Miałem okazję uczestniczyć w projekcie zakorzenionym o DDD. Reklamowaną zaletą tego podejścia miało być usprawnienie komunikacji między programistami a ekspertami domenowymi. W praktyce owi eksperci proponowali swoje z księżyca wzięte pomysły, które trzeba im było wybijać z głowy bądź implementować po ichniemu, gdy się uparli. Te sztywne podziały na odseparowane domeny spowodowały sprawiły, że ładnie się udało stworzyć warstwową architekturę jak z Martina, ale już komunikacja między nimi była męcząca, chociażby dlatego, że każda miała odseparowaną bazę, a czasem kompetencje jednak na siebie nachodziły, szczególnie gdy product ownerzy i eksperci dochodzili do odmiennych wniosków i uznawali, że coś trzeba zrobić inaczej. Ogółem trochę problemów to rozwiązało, trochę wprowadziło, do tego ten nieprzyjemny posmak pewnego fanatyzmu i ewangelicznej wręcz wierności i traktowania wytwarzania oprogramowania w kategoriach jakichś skomplikowanych ideologii (vide "to nie jest prawdziwe DDD" jak trafnie skomentował @Shalom). Ale już np. takie event stormingi były całkiem wesołe.

Swoją drogą, spróbowałem czytać tę Ewangelię według św Vernona, ale strasznie to męczące. Taki mocno nieczytelny bełkot, przez który się mozolnie przedziera, a na końcu i tak nie rozumie o co chodzi.

1
nobody01 napisał(a):

Jak to jest w rzeczywistości? Nie ukrywam, że temat jest efektem mojej frustracji wynikającej z niemożności pojęcia tegoż.

A gdzie opcja nie używam, bo w mojej pracy nie ma sensu, i nie wiem, czy będę używał, bo nie wiem, czy trafię do projektu, w którym DDD będzie miał sens?

3

Z DDD jest jak ze wszystkim innym w programowaniu- powinno się go używać tam gdzie jest taka potrzeba i jest sens. Ponadto jest to proste w założeniach, ale złożone w szczegółach zagadnienie skąd się też biorą niedopowiedzenia i głupie żarty. Do "specjalistów" którzy namiętnie kpią z DDD nie będę się nawet odnosił, bo ktokolwiek podchodzący do jakiegokolwiek tematu w taki sposób stawia pod znakiem zapytania swoją reputację profesjonalisty. Można to podsumować krótkim "nie znam się więc się wypowiem". Ktoś wyżej wspomniał o tym że z DDD jest jak z komunizmem. Ja bym trochę to sparafrazował- tam gdzie DDD było niepoprawnie wprowadzone lub w ogóle nie powinno się go wprowadzać to tak jak z chińskim komunizmem- jest wszystkim innym niż komunizm tylko nie w nazwie. Tak samo bywa z DDD w takich przypadkach- jest DDD tylko w nazwie.

Ogromnym błędem w rozumieniu DDD jest zapominanie o pewnym logicznym podziale- taktyczne i strategiczne DDD. Ludzie często mówią DDD całkowicie ignorując aspekt strategiczny. Owszem, można przy swoim projekcie wykorzystać apekty taktycznego DDD, użyć tego co uważamy za najbardziej przydatne- np. konteksty czy agregaty. Niektórzy stwierdzą że pewne techniki nie są czymś wyłącznie należącym do DDD, czy że wręcz DDD je zapożyczyło. Jak najbardziej mogą mieć rację! Nikt o zdrowych zmysłach nie twierdzi że koncepcja DDD wprowadziła wyłącznie unikalne zagadnienia które nigdy wcześniej nie istniały. Pewne koncepcje zostały zmodyfikowane czy też zdefiniowane na nowo, inne zostały jawnie nazwane. Pytanie więc: co ze strategicznym aspektem DDD? W dużym uproszczeniu, polega on na wszelkich aspektach nie związanych ściśle z kodem- wszelkie sprawy około-biznesowe. Zakłada on współpracę i zaangażowanie nie tylko programistów ale i biznesu. Wszyscy związani z rozwojem produktu powinni rozumieć i aktywnie działać w celu osiągniecia wspólnego celu. Nie powinien istnieć podział na "my biznes i tamci programiści robiący czary-mary między sobą i dający nam owoc swojej pracy". Eksperci domenowi powinni angażować się w takim samym stopniu jak programiści, wszyscy powinni porozumiewać się wspólnym językiem i na codzień wcielać w życie koncepcje DDD. Jest wręcz rzeczą normalną że np. programista organizuje spotkanie z ekspertem domenowym (czyli kimś ze sfery biznesu) w celu sformułowania wspólnego języka. Jeśli ekspert mówi że- w obrębie danej subdomeny- patient to nie jest patient tylko customer, to programista akceptuje to i nie bawi się w mapowanie nasze-nazwy > ich-nazwy tylko implementuje w kodzie takie nazewnictwo jakie obie strony akceptują. Czyli najczęściej właśnie nazewnictwo podane przez biznes (ale nie zawsze). To jest tylko jeden drobny przykład oczywiście, zdaję sobie sprawę że ktoś może nie stosować DDD a również stosować taką praktykę. Jeśli komuś już się nóż w kieszeni otworzył i próbował wylać swoje oburzenie że próbuję przypisać coś "naturalnego" zasługom DDD, proszę jeszcze raz uważnie przeczytać początek tego paragrafu. Reasumując: aspekt strategiczny jest integralną częścią koncepcji DDD, i nie stosując go nie używamy DDD.

Odpowiadając na pytanie tematu- tak, używam. Około 2 lata temu zaczęliśmy pracę nad wprowadzeniem flagowego produktu naszej firmy na rynek brytyjski. O ile wymogiem była integracja z istniejącymi systemami, to mieliśmy całkowitą wolność w doborze narzędzi, architektury i technik w pracy nad nowym systemem. Od początku oparliśmy nasz system o mikroserwisy z wykorzystaniem event-sourcingu i właśnie DDD. Od samego początku wszyscy (programiści i biznes) jasno określili z czym "to się je" i uzgodnili że trzeba to albo wprowadzić w pełni, albo wcale. Tak więc było ogromne zaangażowanie ze strony biznesu i współpraca z managerami oraz product ownerami była i nadal jest przyjemnością, ponieważ wszyscy oni wzięli sobie do serca podstawowe koncepcje właśnie strategicznego DDD. Projekt okazał się takim sukcesem że postanowiono wziąć przykład z naszego podejścia i zaimplementować to ogólnie w całej korporacji.

Tak więc DDD to nie jest wrzucenie kontekstów i agregatów i liczenie na to że będzie dobrze. Wymaga zaangażowania na różnych poziomach firmy, wzajemnego zrozumienia i współpracy oraz- o czym jeszcze nie wspomniałem- zaangażowania wszystkich programistów. Należy ustalić pewne reguły oraz ściśle ich przestrzegać, programiści muszą dobrze rozumieć o co w tym wszystkim chodzi oraz po prostu dostrzegać sens i zalety robienia pewnych rzeczy tak a nie inaczej. Do tego trzeba być kimś co ja nazywam "pragmatycznym dogmatykiem". Co przez to rozumiem? Zasady są uniwersalne, a jak coś jest do wszystkiego to jest do niczego. Zdażają się sytuacje że pewne dogmaty nie pasują czy też się nie sprawdzają, i wtedy trzeba wykazać się pragmatyzmem- ustalić wspólnie co należy zrobić inaczej, dojść do konsensusu i ustanowić precedens. Ale po tym znów trzeba wykazać się dogmatyzmem i trzymać się uzgodnionych wspólnie zasad. Oczywiscie, może się okazać że coś było złym pomysłem i się nie sprawdziło, wtedy trzeba być otwartym na korekty i redefiniowanie zasad. Trzeba więc byś elastycznym, ale w pewnych ogólnie przyjętych granicach.

DDD jak wszystko inne nie jest złotym środkiem. Należy rozumieć jego wady jak i zalety oraz dobrze się zastanowić czy jest sens jego stosowania w konkretnym projekcie. Musi również istnieć ogólna zgodna i chęć wprowadzenia DDD (po już wspomnianym zrozumieniu wad i zalet). Jeden architekt systemu chcący stosować DDD podczas kiedy inni są temu przeciwni lub nie rozumieją jest świetnym przepisem na porażkę.

0
Spearhead napisał(a):

(...)W praktyce owi eksperci proponowali swoje z księżyca wzięte pomysły, które trzeba im było wybijać z głowy bądź implementować po ichniemu, gdy się uparli.

Brzmi jak typowy konflikt na linii biznes-programiści, występujący często i nie mający nic wspólnego ze stosowaniem DDD lub jego brakiem.

(...)ale już komunikacja między nimi była męcząca, chociażby dlatego, że każda miała odseparowaną bazę

Ten sam problem będziesz miał przy korzystaniu z mikroserwisów. Znów- nie ma tu znaczenia stosowanie lub brak DDD.

Ogółem trochę problemów to rozwiązało, trochę wprowadziło, do tego ten nieprzyjemny posmak pewnego fanatyzmu i ewangelicznej wręcz wierności i traktowania wytwarzania oprogramowania w kategoriach jakichś skomplikowanych ideologii

Każdy fanatyzm jest zły. Fanatyzm stosowania DDD jest tylko kolejnym tego przykładem. Innym przykładem fanatyzmu jest anty-DDD, co możesz zobaczyć również w tym wątku.

Swoją drogą, spróbowałem czytać tę Ewangelię według św Vernona, ale strasznie to męczące. Taki mocno nieczytelny bełkot, przez który się mozolnie przedziera, a na końcu i tak nie rozumie o co chodzi.

Ta książka (którą zaledwie kilka miesięcy temu czytałem) jest błędnie postrzegana jako coś co ma wprowadzić do DDD. Nic bardziej mylnego. Jeśli ktoś jeszcze nie zna/nie rozumie DDD niech się za nią nie zabiera, bo wprowadzi więcej zamieszania i pytań niż odpowiedzi.

0

@Aventus: To co polecilbys do przeczytania osobie, ktora chce bardziej szczegolowo poznac DDD?

1

@nobody01: ja nie uczyłem się z jakiejś konkretnej książki. Ogólnie to polecam nie "łykać" DDD w całości tylko "jeść" je po kawałku. Dla programisty który chce poznać temat mimo wszystko najważniejszym (z jego/jej perspektywy) i najciekawszym bedą zagadnienia takyczne, więc zaczął bym od bounded contexts i aggregates. Te drugie są często błędnie rozumiane- ja sam początkowo nie do końca rozumiałem koncepceę, myśląc że np. aggreagte root jest jednym agregatem, a wszystkie inne encje związane z nim są również agregatami. Swojego czasu przeczytałem dosyć lekką książkę DDD Quickly, której autorzy podsumowują główne zagadnienia w zwinnej formie. Książka ma zaledwie ok. 100 stron i była dostępna za darmo w internecie, więc jeśli byś chciał to mogę Ci podesłać PDFa.

Raz jeszcze chcę podkreślić- mimo że poleciłem zacząć od aspektów taktycznych to nie można mówić o DDD ignorując aspekty strategiczne, więc należy o tym pamiętać!

0

Jakich technologii używają osoby które w ankiecie wybrały "Używam"?

1 użytkowników online, w tym zalogowanych: 0, gości: 1