Wątek przeniesiony 2019-07-24 15:19 z przez cerrato.

Czy używacie w pracy DDD?

Czy używasz w pracy DDD?
Używam
24%
24% [11]
Używałem, ale zrezygnowałem
0%
0% [0]
Nie używam, ale mam zamiar
15%
15% [7]
Nie używam i nie mam zamiaru
48%
48% [22]
Nie znam DDD, ale chcę się nauczyć
13%
13% [6]
Odpowiedz Nowy wątek
2019-07-24 14:35
0

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

edytowany 1x, ostatnio: nobody01, 2019-07-24 14:43

Pozostało 580 znaków

2019-07-25 13:03
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.

Pozostało 580 znaków

2019-07-25 13:06
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.

Pokaż pozostałe 7 komentarzy
A poza tym też mam w d wasze bany. :) - BanBlock 2019-07-25 21:28
A ja bym nie chciał by spadł banhammer, bo to nie jest tak, że banujemy jak leci za byle pierdołę, więc mam nadzieję, że BanBlock nie będzie potrzebował bana, bo tacy użytkownicy są fajniejsi niż Ci wymagający bana. - hauleth 2019-07-25 21:30
No dobrze, mój przyjacielu, nie ma problemu. Ja bym też chciał mieć tutaj spokój, a nawet podzielić się z naszą społecznością jakąś publikacją odnośnie do DDD . - BanBlock 2019-07-25 23:49
bo to nie jest tak, że banujemy jak leci za byle pierdołę No oczywiście, że nie :) A nick Gworys za co został zbanowany? - BanBlock 2019-07-26 00:34
Za bycie multikontem dzbana ze zrośniętymi brwiami. - somekind 2019-07-26 02:28

Pozostało 580 znaków

2019-07-25 14:41
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.

edytowany 1x, ostatnio: Spearhead, 2019-07-25 14:42
Taki mocno nieczytelny bełkot, przez który się mozolnie przedziera, a na końcu i tak nie rozumie o co chodzi hehe :D - BanBlock 2019-07-25 15:19
Trzeba było spalić tę książkę albo zakopać na cmentarzu. :D - BanBlock 2019-07-25 15:23
Ewangelia to raczej wg Evansa :) - tdudzik 2019-07-25 15:30
@tdudzik: masz Stary i Nowy Testament :D - Shalom 2019-07-25 15:56
Obraziliście mnie, idę sobie popłakać w kąt. Albo sam sobie dam bana. - BanBlock 2019-07-25 17:22

Pozostało 580 znaków

2019-07-26 02:29
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?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-07-27 14:30
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ę.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Podejrzewam, że to czego część ludzi nie lubi w DDD to po 1. fakt, że większość z tych zasad już istniała tylko pod innymi nazwami, po 2. traktowanie tego jako leku na całe zło, które wprowadzone dobrze rozwiąże wszystkie problemy, jednocześnie zasady DDD są znane głównie wszelkiej maści konsultantom i innym magom, który już czekają aż będą mogli komuś doradzić czy sprzedać swoje książki i szkolenia (oczywiście nie za darmo). - tdudzik 2019-07-27 16:09
Jednocześnie nie widziałem (choć może takie istnieją) materiałów od Google/Facebook/Uber/Netflix/Amazon/Twitter o jakichś success stories z DDD, a firmy te są w stanie robić Software na skale jaką nie robi się go nigdzie indziej. - tdudzik 2019-07-27 16:10
Już nie wspominając o niekończących się dyskusjach "czy coś jest agregatem". Intuicja podpowiada, że jednak da się prościej. - tdudzik 2019-07-27 16:10

Pozostało 580 znaków

2019-07-27 14:38
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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-07-27 14:48
0

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

Pozostało 580 znaków

2019-07-27 15:18
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ć!


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2019-07-27 15:19

Pozostało 580 znaków

2019-07-27 16:11
0

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

Pozostało 580 znaków

2019-07-27 16:36
0

Jakie to ma znaczenie? DDD nie jest zagadnieniem związanym z konkretną technologią. Czy pytasz po prostu z ciekawości?


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
pytam z ciekawości, obastawiam, że większość osób będzie ze świata Java/C# - John Lemon 2019-07-27 18:52
Zapewne tak. Jeśli chodzi o mój obecny projekt to .Net/C#do backendu i React.js do frontu. Bardziej szczegółowe technologie: Redux (zarządzanie stanem we froncie), NServiceBus z MSMQ do komunikacji między serwisami/kontekstami, EventStore do przechowywania eventow (event-sourcing). Read modele trzymamy w SQL Server, chociaż w pewnych konkretnych przypadkach jest to problematyczne i aktualnie robię mały prototyp jako proof-of-concept aby rozważyć trzymanie pewnych modeli w NoSQL. - Aventus 2019-07-27 19:18

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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