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-24 18:39
2

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


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2019-07-24 19:05
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).

Pozostało 580 znaków

2019-07-24 19:10
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 ;)


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
jak myślisz takie rzeczy komplikują się, bo ludzie chcą komercjalizować to w postaci szkoleń / książek, czy może jest jakiś inny powód? - nohtyp 2019-07-24 19:38
Myśle że raczej po prostu ludzie lubią się promować na "znawców" i takich co "zawsze maja rację" i jak sobie ubzduraja że tylko ich wersja XYZ jest tą poprawną to potem wszędzie próbują to tak przedstawiać. - Shalom 2019-07-24 20:28
Jak patrze na Vernona i jego projekt vlingo to mam wrażenie, że to już czysta i niestety szkodliwa komercja. Na twiterze Vernon często zwalcza alternatywne podejścia i projekty, a do tego IMO promuje całkiem słaby kał czasami (z tego vlingo). - jarekr000000 2019-07-24 22:11

Pozostało 580 znaków

2019-07-25 07:09
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"...

Pozostało 580 znaków

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

Pozostało 580 znaków

2019-07-25 09:29
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.


Pozostało 580 znaków

2019-07-25 09:49
W2K
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.

Pozostało 580 znaków

2019-07-25 10:17
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).

edytowany 2x, ostatnio: Markuz, 2019-07-25 10:18

Pozostało 580 znaków

2019-07-25 12:25
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 :)


Java to taki C# tyle że z gorszą składnią.
edytowany 1x, ostatnio: neves, 2019-07-25 12:26

Pozostało 580 znaków

2019-07-25 12:53
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.

edytowany 1x, ostatnio: BanBlock, 2019-07-25 13:03
Pierwszy raz o niej czytałem w książkach Erica Evansa dot. DDD dlatego też nie jestem zawiedzony ;) - Markuz 2019-07-25 14:24

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