Wpis z mikrobloga

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
  • 31
  • Odpowiedz
@sarveniusz: Nie znam PHP ale z punktu widzenia inżynierii oprogramowania to jedyne rozwiązanie żeby mieć czystą domenę to posiadanie 3 osobnych modeli danych. Pierwszy encje bazodanowe, drugi model dziedziny, trzeci DTO i robienie mapowania pomiędzy nimi. Czy jest sens? Moim zdaniem nie.

Od 12 lat w projektach DDD i CQRS (bo nie widzę sensu stosowania DDD bez CQRS, przynajmniej na poziomie separacji zapis/oczyt czyli command handler/query handler) stosuję tylko DTO mapowane
  • Odpowiedz
@MQs:

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.


Pisałem o tym właśnie i o to mi głównie chodzi, że większość projektów nie ma tak złożonej logiki, żeby ORM stanowił problem, a jak stanowi to
  • Odpowiedz
@sarveniusz:

Jedyne czego nie stosuję zawsze to Command/Query Handlery, bo nie zawsze ma to sens.


Dlaczego? Być może to wynika z ograniczeń twojego frameworka? W .NET jest biblioteka Mediatr (pierwszy lepszy przykład użycia https://cezarywalenciuk.pl/blog/programing/mediatr-cqrs-i-wzorzec-projektowy-mediator-w-aspnet-core) i moim zdaniem podkreślam moim :P taki podział w projekcie na commands/queries i odpowiadające im handlery pozwala fajnie uporządkować kod. Nie mam smutnych klas typu serwis czy manager z kilkunastoma metodami długimi na kilkaset loc, tylko pojedyńcze
  • Odpowiedz
@markaron:

Ten link zwraca 404. W sumie to zwykle podchodzę do tego bardzo podobnie, mam jedną metodę w klasie, ale nazywam to zwykle trochę inaczej niż CommandHandler, QueryHandler, a to dlatego, że nie dokładam jakiegoś busa do tego, bo wtedy znowu musiałbym być bardzo restrykcyjny co do zasad i pewnie nie zwracać danych z CommandHandlera. Chyba, że nie masz czegoś takiego na myśli i te handlery normalnie zwracają dane, wtedy pewnie
  • Odpowiedz
@sarveniusz: Po prostu dla mnie jest to dużo czytelniejsze, zwłaszcza gdy mam aplikację, z bogatą dziedziną biznesową i dużą ilością operacji. Zwyczajnie podział na pojedyncze klasy command/query handler, które mają biznesowe nazwy jest bardziej przejrzysty niż trzymanie całej logiki w przykładowej klasie OrdersService, gdzie jest kilka/kilkanaście metod typu read/write i mieszają się implementacje ORMa z czystym SQL.
  • Odpowiedz
@markaron: jasne, też nie lubię takich przerośniętych serwisów, dlatego zwykle to separuję, ale bez busa i zwracam dane z command handlerów, chyba, że są jakieś drivery świadczące o tym, żeby zrobić inaczej.
  • Odpowiedz
@sarveniusz: mnie np. zastanawia czemj zestawiasz strach przed ORM z DDD? Przecierz korzystasz tu normalnie z repozytoriów, tylko ich implementację trzymasz w warstwie infrastruktury. Wtedy w tym repo robisz co chcesz i mozesz sobie korzystać z orm-a.
  • Odpowiedz
@ajgoron: jest to opisane w podlinkowanym artykule, chodzi głównie o narzut ORMa (np. Doctrine), że w obiekcie musisz korzystać z kolekcji doctrinowych co powoduje, że domena nie jest czysta w 100%
  • Odpowiedz