Czy encje w #ddd mogą wymagać zewnętrznych zależności? Zamodelowałem domene gdzie kilka encji jest zależnych od dodatkowych zależności: 1. Usługi dostarczającej aktualny czas aby można to było mockować. 2. Implementacje algorytmu kryptograficznego. Obie te zależności chce wstrzykiwać przez konstruktor. Oczywiście w domenie są tylko ich interface a ich implementacja wyżej. Ma to sens? Szukając odpowiedzi na to pytanie w internacie nie znalazłem nic konkretnego. Dodatkowo nie widzę możliwości skonfigurowania tego w ORM tak jakby właśnie się tego nie robiło. Na logike wydaje mi się, że jeżeli stosujemy SOLID to taka sytuacja jest naturalna. #programowanie
@kywmn: Polecam nie mieszać ORM z DDD, tj. odpowiedzialności Encji i Agregatów bądź innych obiektów domenowych. Wymaga to oczywiście implementacji tłumaczącej jedną warstwę na drugą, ale za to dostajemy obiekty domenowe (parafrazując Food Emperora) "tak czyste że o ja #!$%@?ę" i stosowanie czy testowanie ich staje się przyjemnością samą w sobie ( ͡°͜ʖ͡°)
@kywmn: Rozważyłbym przekazanie tych zależności jako dodatkowe parametry metody, do wykonania której tych zależności potrzebujesz. Albo zamiast usługi dostarczającej aktualny czas, przekazać po prostu aktualny czas. Czyli w uproszczeniu zamiast new Aggregate(time, crytography).Foo(x, y) to new Aggregate().Foo(x, y, time, cryptography);
Co do łączenia DDD z ORM, to faktycznie, książkowo model domenowy powinien być zupełnie niezależny od ORM i wszelkich rzeczy związanych z DB. W praktyce to jest tak, że jak zrobisz
@masterix: W jaki sposób rozwiązuje to problem? Jeżeli encja wymaga zależności w konstruktorze to wciąż entity framework nie będzie wiedział jak stworzyć ten obiekt. Chyba, że da się jakoś rejestrować fabryki do ORM?
@Szajs: Rozwiązałem właśnie w ten sposób już kilka razy ten problem ale bardzo brzydko to wygląda i szukam bardziej eleganckiego rozwiązania.
Co do osobnego data modelu to też uważam, że to proszenie się o kłopoty, dużo dodatkowej
W jaki sposób rozwiązuje to problem? Jeżeli encja wymaga zależności w konstruktorze to wciąż entity framework nie będzie wiedział jak stworzyć ten obiekt.
@kywmn: a dlaaczego się uczepiłeś, że jakiś framework ma Ci budować obiekty domenowe? EF jak mniemam jest jakimś ORMem więc powinien budować co najwyżej encje bazodanowe
@masterix: Z powodów, które wymieniałem we wpisie, który komentujesz. Jeżeli w społeczności nie przyjęło się robić osobnego data modelu dla ORM(ma to minusy, które wymieniłem) to nie będę zawracał kijem rzeki żeby potem tłumaczyć innym programistom dlaczego postanowiłem być wyjątkowy.
@kywmn: to może zobacz jak robi to np Kuba Pilimon i nie gadaj, że nikt tak nie robi. A poza tym jeśli zakładasz, że agregat domenowy i encja bazodanowa u Ciebie to jest to samo, to wkraczamy w kwestie infrastrukturalno językowe, a ja nie znam Twojego stacka, więc nie mogę odpowiedzieć
@masterix: Mam na myśli społeczność .net a Kuba Pilimon jak dobrze kojarzę jest związany z java. Przeszedłem bardzo dużo repozytoriów na github szukając odpowiedzi na pytania, które zawarłem w tym wpisie i w ani jednym nie było dedykowanego data modelu dla ORM. Dwie najbardziej popularne template do clean architecture + ddd + cqrs + es też go nie mają i ORM działa bezpośrednio na modelu domenowym. Na stackoverflow też nic nie
@Szajs: Świetna prezentacja. Jestem Gwidonem. Ten temat się za mną ciągnie już od lat. Dzięki, myślę że mocno mnie to odblokuje.
Dla potomnych: Entity Framework Core aktualnie udostępnia wstrzykiwanie w taki sposób tylko dbContext, przez prywatny konstruktor, ale w przyszłych release planowane jest dodanie funkcjonalności wstrzykiwania dowolnej zależności.
@kywmn: to powszechne podejście, bo dodatkowa translacja to dodatkowy koszt czasowy
Czyli w uproszczeniu zamiast new Aggregate(time, crytography).Foo(x, y) to new Aggregate().Foo(x, y, time, cryptography);
Co do łączenia DDD z ORM, to faktycznie, książkowo model domenowy powinien być zupełnie niezależny od ORM i wszelkich rzeczy związanych z DB. W praktyce to jest tak, że jak zrobisz
@Szajs: Rozwiązałem właśnie w ten sposób już kilka razy ten problem ale bardzo brzydko to wygląda i szukam bardziej eleganckiego rozwiązania.
Co do osobnego data modelu to też uważam, że to proszenie się o kłopoty, dużo dodatkowej
@kywmn: a dlaaczego się uczepiłeś, że jakiś framework ma Ci budować obiekty domenowe? EF jak mniemam jest jakimś ORMem więc powinien budować co najwyżej encje bazodanowe
A poza tym jeśli zakładasz, że agregat domenowy i encja bazodanowa u Ciebie to jest to samo, to wkraczamy w kwestie infrastrukturalno językowe, a ja nie znam Twojego stacka, więc nie mogę odpowiedzieć
Dla potomnych: Entity Framework Core aktualnie udostępnia wstrzykiwanie w taki sposób tylko dbContext, przez prywatny konstruktor, ale w przyszłych release planowane jest dodanie funkcjonalności wstrzykiwania dowolnej zależności.
https://docs.microsoft.com/en-us/ef/core/modeling/constructors#injecting-services
W takim razie zostanę przy przekazywaniu zależności przez parametr metody do następnych release ef core. Dziękuję wszystkim za pomoc.
#dotnet #dotnetcore #