Czy u was w pracy stosuje się Domain Driven Design?

1

Tak jak w tytule. Jestem ciekaw jak często można spotkać w projektach takie podejście i co w ogóle o tym sądzicie.

1

Nie, u mnie w projekcie jest FDD, Feature Driven Design

17

U mnie jest BDD, czyli Byle Działało Design

1

Ciekawe kim jest ten jeden osobnik co dał tak i co to za firma:)

2

Niby nie ma u mnie. Ale teraz trafiłem na projekt z generycznim pseudo repozytoriami + EF i to jest dramat jakis. Aplikacja to niby prosty CRUD a tak skomplikowali, że zwykły delete to jest jakiś rocket science. :/

3
szydlak napisał(a):

Niby nie ma u mnie. Ale teraz trafiłem na projekt z generycznim pseudo repozytoriami + EF i to jest dramat jakis. Aplikacja to niby prosty CRUD a tak skomplikowali, że zwykły delete to jest jakiś rocket science. :/

A co to ma wspólnego z DDD?

1

Generyczne repozytoria to wręcz anty-DDD

4

Dawaj, Dawaj, Deploy...

0

Jak wydzielę jakąś logikę i to ładnie zaimplementuję to jest. Jak tego nie zrobię to nie ma.

0

DDDD - dożywocie and dostatek driven development.

1

Ja robię Deadline Driven Development

0

przynajmniej już wiemy dlaczego większość softu jest mierna :P

0

Od 2017 roku 3 praca pod rząd gdzie albo od zera mamy DDD albo refactor w stronę DDD.

2

Stosuję: давай давай деплой

0

@jarekr000000: W jednej firmie nazwaliśmy takie coś metodyką ułańską: weźmy i zróbmy .

0

Ja stosuję na poziomie strategicznym, tj. zadaje sobie pytanie, w jaki sposób odpowiednio podzielić system, aby nie sięgać lewą ręką do prawego ucha i nie rozpinać parasola w d****je. Na tym etapie zwykle dzieje się największa krzywda.

Na poziomie mikrouslugi, czyli tzw. wzorce taktyczne z którymi 99% osób utożsamia całe DDD - czy ktoś używa repository czy dało, value objectów czy DTO, to zwykle naprawdę wszystko jedno.

1

Ja z kolei coraz częściej zauważam.

SWU

Sp....l Wypuść Uciekaj (do innej firmy)

1

jako że już dużo postów się nazbierało, to czas na odznakę

screenshot-20210928174450.png

0

Pracowalem z ADD (asshole driven development)

0

Czyli tylko 4 osoby dzielą aplikacje na moduły, a ich encje robią cokolwiek więcej niż get i set? :O

Ogólnie mam taką hipotezę, że w każdym systemie większym niż CRUD stosuje się techniki z DDD, nawet jeśli robi się to nieświadomie.

2

W obecnej pracy nie stosujemy DDD w pełnym tego słowa znaczeniu- wyrzystujemy natomiast pewne jego elementy.

W poprzedniej pracy przy ostatnim projekcie stosowaliśmy DDD oraz event sourcing. Do tej pory uważam że był to projekt w którym widziałem najczystszy i najbardziej rozszerzalny (pod względem łatwości dodawania nowych funkcjonalności) kod.

0

Aktualnie nie. Powody to brak kogoś, kto ma praktykę w takim podejściu, oraz odziedziczenie kodu z historią.

3

DDD to głównie wspólne zrozumienie problemu przez biznes i IT: wspólne nazewnictwo i zrozumienie procesów. Cała reszta to techniczne mumbo-jumbo nastawione na sprzedaż kursów

1
Charles_Ray napisał(a):

Na poziomie mikrouslugi, czyli tzw. wzorce taktyczne z którymi 99% osób utożsamia całe DDD - czy ktoś używa repository czy dało, value objectów czy DTO, to zwykle naprawdę wszystko jedno.

Może przez to, że o tym traktują książki o DDD?

nobody01 napisał(a):

Czyli tylko 4 osoby dzielą aplikacje na moduły, a ich encje robią cokolwiek więcej niż get i set? :O

To nie wystarczy, aby mieć DDD.

Jak nie robię całych systemów tylko ich komponenty, i nie mam biznesu, to z definicji nie mogę mieć DDD?

3

u mnie w większości (chociaż już coraz rzadziej) to JJNNB (jebać, jebać, nic się nie bać) - kumpel wprowadził i to chyba najtrafniej opisuje proces. Wynika to z tego, że projekt ma już ponad 25 lat rozwoju za sobą, część w której mój zespół grzebie była przez dłuższy czas zostawiona sama sobie (a właściwie w większości programistom zza wschodniej granicy). Core przepisaliśmy praktycznie od zera i tam już nie ma obawy, że jak dotkniesz w jednym miejscu to się zjebie w dziesięciu innych, ale stary kod dookoła dalej ma takie tendencje. No cóż life is brutal and full of zasadzkas.

5

To że są jakiejś elementy z DDD powszechnie używane to nie znaczy że to jest jakaś uber architektura. O wiele więcej sensownych dla mnie pomysłów wnosi clean architecture przy czy tam naprawde to fency nazwa na SOLID (tyle że na poziomie architektury aplikacji) :D Co do stosowanie elementów z DDD to np. wykorzystywanie VO wynika też z chęci silniejszego korzystania z typów - skoro je mamy zamiast nawalać wszędzie Stringi. Taką tendecje będę mieli głównie korzystający z FP, w takim razie czy FP jest inspirowane DDD? No chyba nie bardzo. Eventy domenowe, to też nie jest coś wymyślonego koniecznie w DDD.
@WeiXiao widziałem książke o DDD gdzie encjami były encje JPA. No kurła rzeczywiście super jakość kodu...

1

To z ilu elementów DDD trzeba korzystać, żeby móc powiedzieć, że robi się DDD? Można mieć małe i duże DDD, tak jak pisał @Aventus

The book introduced the notion of classifying objects into Entities, Value Objects, and Service Objects - what I call the Evans Classification and identifying the concept of Aggregates. I found these filled an important gap in thinking about objects which eluded both programming languages and diagrammatic notations. A particularly important part of DDD is the notion of Strategic Design - how to organize large domains into a network of Bounded Contexts. Until that point, I'd not seen anyone tackle this issue in any compelling way.

1

Ja myślę że ludzie trochę popadają w skrajności, i to po obu "stronach" dyskusji. Z jednej strony są ci którzy na siłę próbują mówić o stosowaniu DDD nawet jeśli tego w ogólnie nie rozumieją (skąd perełki gdzie ktoś ma w kodzie moduł Domain i uważa że robi DDD), a z drugiej jacyś fanatyczni hejterzy DDD (którzy dziwnym trafem są jeszcze głośniejsi od fanatycznych dogmatyków DDD) którzy za wszelką cenę próbują ujmować wpływowi DDD. @nobody01 fajny cytat, bo dobrze podkreśla to o tym chcę napisać. Mianowicie czy się to komuś podoba czy nie, DDD zostało zdefiniowane już trochę czasu temu i w konkretnym kontekście w jakim znajdował się wtedy świat programistyczny, a konkretnie świat pisania złożonego programowania biznesowego. Wiele z jego elementów przeniknęło właśnie poza DDD, jak i wiele elementów znanych wcześniej zostało jakby wpięte w jedną całość.

I tacy fanatycy usłyszą o jakimś konkretnym zagadnieniu- np. value objects- i będą krzyczeć "hurr hurr, ja to używałem i nie potrzebuję do tego żadnego gópiego DDD". To jest bez sensu. Używając całkowicie innego przykładu- teoria względności Einsteina- czy to że opierał się na opracowaniach innych w jakikolwiek sposób ujmuje jego teorii (analogiczny przykład z ludźmi którzy dziwią się że DDD zawiera pewne koncepcje które istniały już wcześniej)? Czy to że dziś każdy bierze za pewnik satelity nad głowami w jakikolwiek sposób ujmuje teorii Einsteina, dzięki której te satelity biorąc pod uwagę dylatację czasu synchronizują się (analogiczny przykład z kimś kto używa elementy zaproponowane przez DDD, i ponieważ jest do nich przyzwyczajony próbuje odrzucić fakt że to właśnie DDD zawdzięcza te elementy)?

2
nobody01 napisał(a):

To z ilu elementów DDD trzeba korzystać, żeby móc powiedzieć, że robi się DDD?

Dobre pytanie, sam chciałbym poznać na nie odpowiedź. Ale obstawiam, że sekta nie ma jednej wspólnej wizji.

Można mieć małe i duże DDD, tak jak pisał @Aventus

A może średnie, z ostrym sosem? :P

Może nie byłoby tego "hejtu", gdyby nie stosowano fikołków w rodzaju nie wyszło na poziomie struktury kodu, więc udawajmy, że od początku chodziło tylko o komunikację, kod nie jest ważny. I koniecznie napiszmy nową książkę, jest jeszcze tyyyyle kolorów!
Bo pewnie fajnie się dogadywać z biznesem, tylko jak kod jest szambem spaghetti z cieknącymi abstrakcjami, to programistom, którzy się starają robić coś sensownego nie jest fajnie. I nie pomogą tłumaczenia, że no przecież mamy DDD, nikt nie jest lepszy od nas.

2

Dobre pytanie, sam chciałbym poznać na nie odpowiedź. Ale obstawiam, że sekta nie ma jednej wspólnej wizji.

Sekty raczej mają to do siebie, że wizja jest wspólna, bo jest jedyna i "słuszna" wizja kontrolowana odgórnie. W każdym zdrowym środowisku jest miejsce na dyskusje, różne interpretacje oraz próbowanie znalezienia pewnych (nie wszystkich) uniwersalnych zasad drogą konsensus (co często idzie w parze z metodą prób i błędów). Także uszczypliwość z sektą raczej nie trafiona. Ja bym powiedział że jest wręcz odwrotnie- jak na razie spotykam się z sektą anty-DDD, bo ci mają wspólną wizję że DDD to zło i tyle.

Może nie byłoby tego "hejtu", gdyby nie stosowano fikołków w rodzaju nie wyszło na poziomie struktury kodu, więc udawajmy, że od początku chodziło tylko o komunikację, kod nie jest ważny. I koniecznie napiszmy nową książkę, jest jeszcze tyyyyle kolorów!

Ja się z czymś takim nie spotkałem, ale nie twierdzę że takie patologie nie mają miejsca. Z pewnością mają, tak jak i w wielu innych dziedzinach. Środowisko DDD nie jest tu żadnym wyjątkiem. Ale wiadomo, zawsze ktoś może popadać w efekt potwierdzenia i traktować patologie w DDD jako ewidentny i niepodważalny przykład tego jakim złem jest właśnie DDD.

Bo pewnie fajnie się dogadywać z biznesem, tylko jak kod jest szambem spaghetti z cieknącymi abstrakcjami, to programistom, którzy się starają robić coś sensownego nie jest fajnie.

Znów- takie patologie mogą mieć miejsce wszędzie, nijak nie świadczy to jakimś konkretnym podejściu.

nikt nie jest lepszy od nas.

Tia, grunt to dorabiać jak najwięcej przykładów do własnego przekonania. Nawet jeśli przykłady te są wyimaginowane.

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