Siema, pisze aplikacje DDD (a przynajmniej chcialbym) i mam pewien problem techniczny. Otoz nie wiem jak rozwazyc problem ww. w tytule. Podchodze do tematu code-first, wiec entity framework wygenerowal mi wlasne encje. Jak powinienem postapic w tej sytacji ? Spotkal sie ktos z was w takiej sytuacji?
0
1
W code first to ty piszesz encje a nie EF.
0
W sumie to podepnę się do tematu. O ile encje możemy traktować jako Persistent Model, to wychodzi potrzeba oddzielenia jeszcze od niego modelu domenowego (Domain Object). Wydaje mi się, że o to chodzi autorowi. Sam nie bardzo jeszcze wiem, z rozwiązań jakie widziałem w Internecie to:
a) nie rozdzielanie jednak obu obiektów, bardzo brzydkie
b) wrzucenie do modelu domenowego przez konstruktor encji na której ów model by sobie manipulował. Odpada robienie czarów z mapowaniem Domain Model <=> Persitent Model
c) traktowanie modelu domenowego jako całkowicie odizolowanego bytu od EFowej encji, teoretycznie najbardziej poprawne. Z tym że nie wiem jak zrobić tutaj wspomniane mapowanie, zwłaszcza w połączeniu z EFem który encji domenowych by nie śledził. Dobrze by było, gdyby ktoś kompetentny to wyjaśnił, bo mimo przerzucenia tony artykułów o DDD to dalej mam sporo niejasności.
3
W teorii powinno się robić C, ale jest to ciężkie i żmudne, więc w praktyce A jest w większości przypadków wystarczające.
W podejściu code first w EF, encje są w miarę czyste, jest wprawdzie niewielki narzut ze strony EF na to jak te encje mają wyglądać, no ale z mojej perspektywy nie wygląd to aż tak brzydko. Jeśli chcesz osiągnąć większą czystość, zawsze możesz spojrzeć w kierunku NHibernate, który uchodzi za bardziej ddd friendly od EF.
0
Macie moze jakies przykladu kodu ? (np. z githuba), jest tego sporo, ale przez to nie wiem co warte uwagi. Albo brakuje VO, agregatow fajnych, domain services, albo wszystko pieknie ale nie ma EF :D
1
Taka anegdotka: o wskazanie dobrego przykładu open surcowego projektu realizowanego w DDD był poproszony Eric Evans (bodaj na twiterze, albo w jakimś podcaście to usłyszałem), i odpowiedział coś w stylu: że na jego stan wiedzy, taki projekt nie istnieje :D.
0
EntityPamerano napisał(a):
a) nie rozdzielanie jednak obu obiektów, bardzo brzydkie
A, że programiści lubią brzydki kod, to i najpopularniejsze. Tylko wtedy nie ma DDD.
Nie da się napisać "encji" EF, które byłyby persistence ignorance. Trzeba mieć publiczne właściwości, dozwolony jest jeden typ kolekcji, nie można mieć kolekcji readonly, do tego oddzielnie id i navigation property (to łamie nawet DRY, a co dopiero DDD).
b) wrzucenie do modelu domenowego przez konstruktor encji na której ów model by sobie manipulował. Odpada robienie czarów z mapowaniem Domain Model <=> Persitent Model
Co to za zmiana, gdy DM jest i tak świadomy istnienia PM?
c) traktowanie modelu domenowego jako całkowicie odizolowanego bytu od EFowej encji, teoretycznie najbardziej poprawne. Z tym że nie wiem jak zrobić tutaj wspomniane mapowanie, zwłaszcza w połączeniu z EFem który encji domenowych by nie śledził. Dobrze by było, gdyby ktoś kompetentny to wyjaśnił, bo mimo przerzucenia tony artykułów o DDD to dalej mam sporo niejasności.
Ale po co ORM miałby śledzić obiekty logiki biznesowej?
Mapowanie DM => PM zrobić łatwo, bo dane wyciągnie się z getterów. W drugą stronę trzeba użyć konstruktora, więc już trudniej, ale tak czy siak, kwestia konfiguracji AutoMappera albo czegoś takiego jak dla mnie.
No i ogólnie ja wyznaję zasadę, żeby zamiast podążać za utopią robić rzeczy sensownie. DDD to nie jest rozwiązanie do CRUDów.
0
No i ogólnie ja wyznaję zasadę, żeby zamiast podążać za utopią robić rzeczy sensownie. DDD to nie jest rozwiązanie do CRUDów.
Zgadzam sie, ale tez niedokonca, bo w pracy mamy aplikacje (DDD-lite huehue) i jest to, bym powiedzial bardziej skomplikowany CRUD, ale domena jest na tyle istotna i dosc skomplikowana (akurat to jest nasz wlasny produkt), ze zdecydowalismy sie na DDD, ja przychodzac do firmy, bardziej zrozumialem domene, dzieki samemu kodowi, wiec jezeli jest duzo zaleznosci, duzo nazewnictwa, to jest mega +. Nie siedze wtedy na spotkaniach jak glupek ;)
@somekind podales fajny sposob, zapewne jestes o wiele bardziej doswiadczony (dopiero raczkuje na backendzie), masz moze jakis prosty przyklad na githubie, czy dobre DDD to temat tabu, bo mam takie wrazenie ;p
1
Jeśli domena skomplikowana, to DDD może się sprawdzi, ale to nie znaczy, żeby je stosować także do CRUDowych kawałków. Ja przez sensowne zastosowanie DDD rozumiem właśnie jakieś skomplikowane procesy biznesowe, które operują np. na 100 obiektach, z których tylko 5 czy 10 trzeba utrwalać w bazie. Wówczas przepisanie ich na obiekty warstwy dostępu do danych jest naprawdę najmniejszym problemem, nawet jeśli robi się to ręcznie.
Przykładów nie mam, poza tym wątpię żeby w ogóle istniały sensowne proste przykłady DDD.
Bo proste przykłady mają niestety to do siebie, że ukrywają 90% zagadnienia i potencjalnych trudności, dlatego wszystko w nich jest łatwe, przyjemne i działa... Tylko tak naprawdę nie dają żadnej wiedzy jak rozwiązywać realne problemy.
0
EntityPamerano napisał(a):
c) traktowanie modelu domenowego jako całkowicie odizolowanego bytu od EFowej encji, teoretycznie najbardziej poprawne. Z tym że nie wiem jak zrobić tutaj wspomniane mapowanie, zwłaszcza w połączeniu z EFem który encji domenowych by nie śledził.
Ja zazwyczaj robię interfejs IMapper z metodą TTo Map<TFrom, TTo>(TFrom from) i w konkretnej implementacji używam AutoMappera, który załatwia mi mapowanie DM na PM w większości przypadków, a tam, gdzie się nie da, to robię dedykowaną implementację IMapper dla danych typów i tam ręcznie przepisuję jak trzeba.
W drugą stronę idzie tak samo, przy czym mam wrażenie, że tutaj częściej muszę posiłkować się własnym kodem, a trudniej jest mi to zmapować AutoMapperem przez konwencję. A dokładniej: może nie tyle trudniej, co ten kod wcale nie jest krótszy, niż ręczne przepisanie czegoś tam.
Zostają kwestie śledzenia obiektów i wewnętrzne sprawy biblioteki. EF nie musi śledzić obiektów domenowych (bo i po co), zazwyczaj trzeba mu explicite powiedzieć, co się z danym obiektem stało, więc warstwa dostępu do danych explicite musi ustawić stan zmapowanego obiektu persystencji, a ten może wywnioskować po wartości id obiektu.
0
Fajnie że temat tak się rozwinął, ogólnie jest to nowy projekt (do pierwszej pracy) więc zdecydowałem się na nhibernate, trochę poczytalem i ta opcja wydaje mi się lepsza bo dużo kodu nie jest naklepane w tym ef.
Ogarnąłem trochę ef, więc jakaś tam wiedzą będę mógł się pochwalić.
Myślę że temat wycisnal odpowiedź ( do powyższego tematu posta), ja akurat wybrałem inną drogę ale odpowiedź do tematu można uważać za zamknięty. W takim razie temat do zamknięcia.