O co chodzi z Domain Driven Design?

Design czyli projektowanie, a nie kodowanie

Daniel_O napisał(a):

8 lat programuję po różnych korporacjach i ani razu nikt mi o tym nie gadał w żadnej firmie, normalnie się pracowało i jakoś doszedłem do pozycji Tech Leada i tak naprawdę ja wciąż nie wiem o co chodzi w tym Domain Driven Design? Co to jest? Ja tego nie umiem.

Dobrze rozumiem, że czujesz się od innych lepszy, bo czegoś nie umiesz? A agendy konferencji są znane, jak Cię coś nie interesuje ani jest Ci potrzebne to nie słuchaj. Strasznie atencyjny ten post wyszedł.

Dla równowagi powinien być jeszcze tu post seniora z 30-letnim stażem, który będzie udowadniał, że jemu żadne wzorce nie bylo potrzebne i żyje.

W Domain Driven Design chodzi o to, że projektujesz system, biorąc sobie problem biznesowy i powiązane z nim procesy jako centrum rozwiązania.
Klasycznie zaczyna się to od sesji event stormingowej, na której jest biznes i developerka i robią burze mózgów odnośnie wydarzeń, które muszą istnieć w domenie.
Pięknie się DDD uzupełnienia z EDA i w sumie bez niego nie istnieje i pięknie idzie też wraz z mikroserwisami.
Jest masa literatury na ten temat i polecam, bo chociaż na takiej sesji event stormingowej nigdy nie byłem to wydaje się to być bardzo rozsądne i fajne podejście do tworzenia oprogramowania.
Z racji tego, że zamykamy domenę to stąd Clean Architecture, bo jak się tech zmieni to rozwiązanie domeny już będziemy mieli i jest framework agnostic.

TLDR: behaviour > data

A jak kodzisz tyle lat i nie jesteś w stanie tego pojąć to zostawię bez komentarza

DDD to nie był ten pattern z "repository classes"? Generalnie dużo abstrahowania co do małych projektów jest overkillem :P

Definicja DDD w jednym zdaniu:

W DDD chodzi o to by wszystkie strony zaangażowane w powstawanie oprogramowania używały wspólnego wszechobecnego języka domenowego do rozwiązania problemu co ma ułatwić komunikację, i aby dzielić większe problemy na mniejsze (nieśmiertelne divide-and-conquer).

Ogólnie Eric Evans zauważył że różne strony zaangażowane w powstanie oprogramowania, strona biznesowa, architekci, programiści, testerzy, używają różnego języka i tworzą własne modele powstającego oprogramowania (które często się rozsynchronizowują z czasem). Więc idea jest by wypracować wspólny język najlepiej wywodzący się z domeny problemu, i dążyć w ideale do jednego modelu nad którym pracują wszyscy zainteresowani. I tym modelem właśnie ma być kod powstającego oprogramowania, i co za tym idzie są zaproponowane pewne wzorce projektowe by to ułatwić. Ale jest to sprawa drugorzędna, bo głównie chodzi o to by wszystkich przybliżyć do siebie i żeby pracowali razem ze sobą jak najbliżej, bez tworzenia modeli zrozumiałych tylko dla poszczególnych grup ludzi.

Także jak najbardziej można robić i dojść do DDD naturalnie i nieświadomie jak się ma zgrany zespół.

Jak się nie osiągnie tego naturalnie, no to właśnie mamy różne techniki prezentowane na konferencjach, mówiące głównie o tym jak zbliżyć biznes do programistów, jak ułatwić im rozmawianie ze sobą, skoro naturalnie tego nie potrafią osiągnąć.

Cały twój wywód jest błędny bo skupiłeś się tylko na kodzie (wzorce taktyczne DDD, ktore w mniejszych projektach faktycznie mogą być overkillem) całkowicie pomijać wzorce strategiczne, czyli odkrywanie i destylacja domeny, definiowanie wspólnego języka, wydzielanie kontekstów ograniczonych i wiele więcej, mających na celu zsynchronizowanie biznesu i IT jak wyłożył @neves.

No i warto wspomnieć, że można i powinno się stosować strategiczne DDD w projekcie każdego rozmiaru.

Do tego strategiczne DDD jest podstawą przy projektowaniu systemów opartych o architekturę mikrousługową bo ładnie widać jak rozkładają się poszczególne usługi, zależności pomiędzy nimi i odpowiedzialności.

I to wszystko zanim napisaliśmy jakąkolwiek linijkę kodu.

Nie wydaje wam się że z całego DDD wartościowe to w zasadzie jest tylko wprowadzanie biznesowego nazewnictwa zidentyfikowanych procesów i ich składników,a taktyczne i strategiczne DDD lepiej opisują pojęcia jak skalowalność , throughput, latency, AP/CP , integralność danych, transakcyjność. Czy nie należy po rozpoznaniu procesów i ich wymagań skupić się tylko na ich grupowaniu w usługi zwracając uwagę na unikanie transakcji rozproszonych( kosztem replikacji danych), podobne zbiory danych, te same wymagania co do skalowalności, wydzielanie procesów o rożnych wymaganiach read/write , throughput, latency. Potem może się okazać że w jeden serwis to lepiej wsadzić jakiś proces z innego bounded contextu bo unikamy transakcji rozproszonej a niefunkcjonalne wymagania mamy te same. Jest bezpieczniej i prościej, a strategiczne DDD idzie papa. Przerobiłem trochę kursów o projektowaniu systemów, microservices design patterns, wiele przykładowych systemów na miliony użytkowników od architekta Googla - w ŻADNYM z nich nie padło słowo DDD.

Daniel_O napisał(a):

Też macie takie odczucie? Czy to jest jakiś sposób na robienie hajsu na Juniorach? Coś jak sprzedawanie dawniej garów po wioskach czy poduszek leczniczych?

Tak. Dawno już nie programuję stricte, ale pamiętam kilka lat temu to był dramat. Wielu szkoleniowców postanowiło sobie wziąć temat DDD pod swoje skrzydła, pewnie chcieli dobrze, ale wyszło bardzo niesmacznie - bo odbierałem to jako "hej, kup nasze szkolenie, bo sam nie dasz rady z netu, to jest trudne, ale z nami dasz radę i wejdziesz do ekskluzywnego klubu znawców DDD i będziesz lepszy od tych żałosnych CRUDowców co tylko gettery i settery piszą".

A szkoda - bo DDD jest zbiorem fantastycznych praktyk. Nie zawsze się sprawdza, no ale to chyba znając DDD wiemy gdzie się nie sprawdzi. :)

DDD to w skrócie zbiór pewnych metodologii metodyk. Ich celem byłoby wytworzyć oprogramowanie które jest niezależne od zewnętrznych elementów (jak baza danych, io, system), a skupia się na zasadach biznesowych - takich które byłyby utrzymywanie nawet w przypadku braku tego softu.

Ciężko to opisać w jednym zdaniu, wymagałoby pensie kilkunastu godzin przyswajania tematu.

i teraz pięknie zestawmy to z tym, ze biznes nie umie formułować wymagań tylko przychodzi z „wizja” która dopiero rozwija się w trakcie developmentu i potrafi core wizji obrócić o 180* :)

Pomijam, ze te naprawdę ogromne korpo które zleca w SH projekty mało kiedy chce marnować czas na dodatkowe spotkania itd. Zazwyczaj PO jest po stronie SH a jak nie spodoba się interpretacja wizji to po prostu więcej z danym SH nie robią xD.

Wiec często ciężko skupić się na „behavior” i projektować według tego bo po prostu to nie istnieje :p

Nie wiem o co chodzi w DDD.

Jedno użyteczne pojęcie, które poznałem to Bounded Context.

Cała reszta jest jakaś mętna.

Agregat, Encja, Repozytorium brzmią ciekawie, ale w postaci jakiej są prezentowane w DDD, nie mają dla mnie sensu.

DDD to bardzo proste podejście do rozwijania oprogramowania gdzie domena projektu jest w jej centrum ale wszędzie (takze tutaj) znajdą się ludzie którzy pozjadali wszystkie rozumy i nie potrafią tego w prosty sposób wytłumaczyć tylko po to by się swoim słowotokiem poflexowac przed innymi

szmeterling napisał(a):

Nie wydaje wam się że z całego DDD wartościowe to w zasadzie jest tylko wprowadzanie biznesowego nazewnictwa zidentyfikowanych procesów i ich składników,a taktyczne i strategiczne DDD lepiej opisują pojęcia jak skalowalność , throughput, latency, AP/CP , integralność danych, transakcyjność. Czy nie należy po rozpoznaniu procesów i ich wymagań skupić się tylko na ich grupowaniu w usługi zwracając uwagę na unikanie transakcji rozproszonych( kosztem replikacji danych), podobne zbiory danych, te same wymagania co do skalowalności, wydzielanie procesów o rożnych wymaganiach read/write , throughput, latency. Potem może się okazać że w jeden serwis to lepiej wsadzić jakiś proces z innego bounded contextu bo unikamy transakcji rozproszonej a niefunkcjonalne wymagania mamy te same. Jest bezpieczniej i prościej, a strategiczne DDD idzie papa. Przerobiłem trochę kursów o projektowaniu systemów, microservices design patterns, wiele przykładowych systemów na miliony użytkowników od architekta Googla - w ŻADNYM z nich nie padło słowo DDD.

W punkt, to malo powiedziane. Stary, nie wiem ile Ci placa, wiem jednak, ze stanowczo za malo.