[sarveniusz]

Wielokrotnie widziałem próby podejścia do DDD na tyle komplikujące całe rozwiązanie, że postanowiłem o tym napisać kilka słów. Mam wrażenie, że świat programistów trochę zachłysnął się modnymi ostatnimi czasy konceptami jak właśnie DDD i wychodzą z tego takie kwiatki jak strach przed ORM, który nie oszukujmy się w przypadku poprawnego zastosowania zaoszczędza sporo pracy. Często mimo nawet nieskomplikowanej domeny programiści celują w stuprocentowo czystą domenę i unikają korzystania z narzędzia, które powoduje jakiś drobny narzut, a w efekcie komplikują system. Co o tym myślicie?

https://sarvendev.com/2022/10/an-absolutely-clean-domain-or-just-common-sense/

#programowanie #php #ddd

[komandor_kres]

@sarveniusz: tak

[h.....s]

@sarveniusz: teraz jest moda na DDD i wszyscy próbują ładować to gdzie się da tak samo jak kiedyś z NoSQL DB czy mikroserwisami, są to oczywiście bardzo dobre rozwiązania, ale nie zawsze konieczne

[yhbgrobdoivbvwamsv]

@sarveniusz: O Jezu, kolejny dev piszący blogi i głębokie przemyslenia xD
Ja nie wiem czemu ta branżą przyciąga tylu filozofów

[Saly]

@sarveniusz: raz pisałem taki serwis bez żadnego mapowania tj. jedyne co miałem to struktury wygenerowane przez protoc i na tych strukturach robiłem wszystko tj. obsługa gRPC, logika biznesowa i baza danych. Takie podejście sprawdza się jak logiki jest bardzo mało, ale im dalej w las tym gorzej. Nie wyobrażam sobie pisanie czegoś bardziej skomplikowanego bez osobnego modelu na logikę, który jest niezależny od zewnętrznych systemów.

teraz jest moda na DDD i

[Saly]

@sarveniusz: odnośnie Using ORM, but not use the full potential to za bardzo nie widzę sensu. ORM to tylko szczegół implementacyjny i nie chcę się go uczyć tak, żeby robić fikołki. Naturalnym podejściem jest zawołanie jakiegoś SQLa i zmapowanie go na jakiś obiekt pośredni. Takie coś łatwo się debuguje i rozwija. Przy takim podejściu nie muszę się uczyć żadnego frameworka (również reszta devów, więc spada poziom złożoności), bo podejście "wołam SQLa

[croppz]

@Saly: w jakich językach piszesz?

[Saly]

@croppz: głównie go

[MacDada]

unikają korzystania z narzędzia, które powoduje jakiś drobny narzut, a w efekcie komplikują system

@sarveniusz: to są dwa oddzielne argumenty

jak ktoś unika ORMa bo robi DDD i mu ORM przeszkadza -> okejka

jak ktoś unika ORMa bo wydajność/narzut -> okejka

eeee? to unikać ORMa zawsze? nope.

kompromisy: używam ORMa Doctrine w 9/10 sytuacji. co prawda nie da się wszystko idealnie czysto, żeby domena była totalnie niezależna od ORM, ale da

[sarveniusz]

@yhbgrobdoivbvwamsv: faktycznie rozkmin filozoficznych to się w branży zrobiło całkiem sporo, ale w tej sytuacji, którą opisałem nie widzę podobieństwa, bo jeśli o takich sprawach nie powinniśmy gadać i "filozofować" to o czym w takim razie? ( ͡° ͜ʖ ͡°)

@Saly: w tym miejscu chodziło o wrzucanie do projektu skomplikowanego ORMa, a korzystaniu z niego na zasadzie tylko anemicznych modeli i mapowania do bazy, gdzie zamiast

[croppz]

@Saly: no i pewnie stąd różnice w poglądach. PHP ma IMO bardziej ustabilizowaną sytuację, jak tworzysz projekt na symfony i doctrine to możesz bezpiecznie założyć, że przez kolejne 10 lat nic się w tym temacie nie zmieni. Możesz też bezpiecznie założyć, że każdy nowy dev wchodząc do projektu będzie obie te rzeczy dobrze znał.

Separowanie się od frameworka nie jest darmowe, zwiększa stopień skomplikowania i ilość potrzebnego kodu. IMO temat sprowadza

[Saly]

no i pewnie stąd różnice w poglądach. PHP ma IMO bardziej ustabilizowaną sytuację, jak tworzysz projekt na symfony i doctrine to możesz bezpiecznie założyć, że przez kolejne 10 lat nic się w tym temacie nie zmieni. Możesz też bezpiecznie założyć, że każdy nowy dev wchodząc do projektu będzie obie te rzeczy dobrze znał.

@croppz: dużo zależy od community języka. W go większość używa standardowego database/sql (lub modyfikacji), który jedyne co zapewnia

[sarveniusz]

@croppz: tak jak pisałem w artykule, nawet jakby trzeba było framework zmienić to nie powinno to być straszne, bo jak skorzystamy z Doctrine do zapisu agregatów z DDD to pewnie będziemy mieli tylko zależność do małej paczki doctrine/collections, więc można założyć scenariusz, że paczka będzie nadal rozwijana, a wtedy do np. CycleORM powinno być łatwo przejść.

Warto tylko pamiętać o automatyzacji i jakiejś weryfikacji reguł architektonicznych za pomocą phparch czy deptrac

[croppz]

@sarveniusz: no ja tam jestem leniwą bulwą i na szczęście z takimi samymi leniwymi bulwami pracuję, mamy mapowanie w atrybutach bezpośrednio na naszych anemicznych encyjkach i jest w pytę.

Regułę mamy prostą, stopień izolacji jest odwrotnie proporcjonalny do stabilności dependenciesa. Symfony, doctrine i postgresa uznaliśmy za stabilne. ¯\_(ツ)_/¯

[sarveniusz]

@croppz: czyli macie translację agregat DDD -> anemiczna encja ORM -> zapis i odwrotnie przy pobieraniu?

[croppz]

@sarveniusz: tak formalnie to nawet agregatów nie mamy. xD

Raczej po prostu input DTO -> jeden lub parę powiązanych entity -> baza, w drugą stronę analogicznie tylko najczęściej DTOsy inne. A logika sobie radośnie traktuje encje jako bazodanowe DTOsy i ma w sumie w dupie czy pracuje z dtosem, czy z encją.

No i entity manager ze wszystkimi swoimi persistami, removami i flushami wypchnięty zawsze na top level, znaczy controller/command/handler. (

[sarveniusz]

@croppz: to chyba nie poruszamy tego samego tematu jednak, bo ciężko tutaj mówić o DDD ( ͡° ͜ʖ ͡°)

[kobrys13]

@sarveniusz: .

[MQs]

@sarveniusz: Taka separacja warstwy danych to nie jest bezpośrednio DDD, tylko clean/onion/hexagonal architecture. Oczywiście ma ona sens kiedy jest jakaś logika biznesowa do testowania, a nie prosty CRUD. Zgadzam się też, że wciskanie na siłę całego leksykonu DDD (szczególnie w php opartym o izolowane procesy, gdzie z automatu masz vertical slice) wygląda śmiesznie.

[sarveniusz]

@MQs: chyba też nie do końca o tym samym mówimy, bo ja krytkuję podejście do DDD w taki sposób, że porzucamy ORM całkowicie, albo nie wykorzystujemy go w 100% mimo, że logika jest względnie prosta i nic nam to nie daje. Przykłady są w artykule, który podałem. Separacja domeny i pozostałych warstw to inna sprawa i to jest pożądany efekt jak najbardziej.

[MQs]

@sarveniusz: Tylko, że odrzucanie ORM (lub części jego funkcjonalności) w ten sposób jest podyktowane właśnie izolacją domeny. Jeżeli nic to nie daje to faktycznie można olać temat, ale moim zdaniem równie poważnym problemem jest łapanie się na haczyk "instant gratification" narzędzi, bo trudno się z niego zerwać i potem widzi się jeszcze głupsze konstrukcje walczące z frameworkiem albo ignorowane/nadmiarowe testy.