Podstawy DDD i projekt projektu ASP.NET MVC

Question

Dwie części pytania

Posiadam agregat produktu, który ma;

Ceny PackagingOptions ProductDescriptions zdjęcia produktów itp

Mam modelowane jednego repozytorium produktu i nie tworzyć repozytoria indywidualne dla każdej z klas potomnych. Wszystkie operacje db są obsługiwane przez repozytorium produktu.

Czy poprawnie rozumiem koncepcję DDD? Czasami przychodzi mi do głowy, że posiadanie repozytorium dla powiedzmy opcji pakowania może ułatwić mi życie, bezpośrednio pobierając opcję pakowania z bazy danych, używając jej identyfikatora, zamiast pytać repozytorium produktu, aby znalazł je w swojej kolekcji PackagingOptions i podać to do mnie ..

Druga część jest zarządzanie zmienił tworzyć operacje przy użyciu szkieletu ASP.MVC

jestem obecnie próbuje zarządzać dodać edycji usuń tych kolekcjach dziecięcych produktu przez kontrolera produktu (brzmi dobrze?).

Jednym z wyzwań, przed którym teraz stoję, jest;

Gdybym edytować konkretną opcję pakowania produktu poprzez

mojadomena/product/editpackagingoption/10

Mam dostęp do identyfikatora opcji opakowań

Ale ja nie mam Identyfikator produktu sam w sobie i to zmusza mnie do napisania zapytania, aby najpierw znaleźć produkt, który ma tę konkretną opcję pakowania, a następnie edytować ten produkt i opcję uwielbienia opakowania. Mogę to zrobić, ponieważ wszystkie opcje pakowania mają swój unikalny identyfikator, ale to się nie powiedzie, jeśli mam kolekcje, które nie mają unikalnego identyfikatora.

że czuje się bardzo źle ..

Kolejna opcja myślałem wysyła zarówno identyfikatorów produktów i Opcja opakowania na URL podobnego;

mydomain/product/editpackagingoption/3/10

Ale nie jestem pewien, czy to jest dobry projekt albo.

Tak więc jestem w pewnym momencie, że jestem nieco zdezorientowany. może mieć fundamentalne nieporozumienia wokół tego wszystkiego ...

Byłbym wdzięczny, jeśli znosisz długie pytanie i pomóż mi to połączyć. dzięki!

Answer 1

Moim zdaniem to jedna z tych błotnistych rzeczy, które pojawiają się w DDD.

W kodzie traktuję zagregowany katalog główny jako kontener dla dowolnych "relacji", które on posiada, i dowolnych Obiektów Obiektów, które nie mogą istnieć bez głównego Agregatu.

Na przykład, weźmy przykład Customer-> Order-> LineItem-> Product, który został zabity na śmierć. Łączny katalog główny, tak jak go wyświetlam, jest klientem w tym scenariuszu. To oznacza, że ​​nie zawsze chcesz dostać się do zamówienia przez klienta.Możesz chcieć znaleźć zamówienia w określonym dniu.

Włączając go po swojej stronie, nie będziesz mieć również klienta, który nie ma zamówienia. Obaj są w nieco symbiotycznej relacji, więc jeden nie jest głównym źródłem drugiego.

Chodzi o to, że nie trzeba ładować klienta za pomocą zamówienia, ale niekoniecznie trzeba załadować zamówienie za pośrednictwem klienta.

Począwszy od zamówienia, jest jednak mało prawdopodobne, że chcesz po prostu pobrać LineItem i na pewno nie będziesz tworzyć ich bez zamówienia. W tym celu Zamówienie służy jako brama do LineItems. LineItems nie potrzebuje własnego kontrolera lub repozytorium. Istnieją one tylko w samym Zamówieniu i jako takie są częścią Zamówienia (w tym przypadku Zamówienie staje się zbiorczym katalogiem głównym) i zarządzane są przez Podmiot Zamówienia.

Ale, LineItem prawdopodobnie będzie mieć związek z produktem w systemie. Produkty posiadałyby własne kontrolery, repozytoria, itp., Ponieważ mogą istnieć poza głównym katalogiem Aggregate.

Podsumowując moje wędrówki, staram się patrzeć na to w ten sposób: jeśli Jednostka może istnieć sama, powinna mieć kontroler. Podmioty, które nie mogą istnieć samodzielnie (LineItems w tym przypadku) powinny być zarządzane tylko przez ich kontener (root agregatu).

Czy jakiś purystek DDD poprawi mnie, jeśli/gdzie się mylę?

Jeśli chodzi o drugą część pytania, potrzebowałbym więcej szczegółów na temat tego, jak wyobrażasz sobie pracę tych innych podmiotów. Z tym, co tu napisałeś, wyobrażam sobie, że PackagingOptions są powiązane z produktem i będą częścią głównego katalogu produktu. Teraz, zakładając, że je edytujesz, błagasz o to, czy jest to tablica przeglądowa w systemie, czy też są one wartościami jednorazowymi i jako takie powinny być traktowane jako obiekty wartości?

Answer 2

Kaiwalja,

Odnośnie swojej Ostatni komentarz (bezstanowym http):

To zależy od kontekstu. Zanim przejdę do szczegółów, powiem ci podstawową zasadę dotyczącą agregatów:

Agregaty definiują grupę powiązanych obiektów, które należy traktować jako pojedynczą jednostkę w celu zmiany danych.

Jest to niezwykle ważne. Celem posiadania Aggregates jest wymuszanie niezmienników. Na przykład możesz mieć zasady takie jak "Zamówienie nie może przekroczyć 500 USD". Następnie, w celu egzekwowania tej zasady, umieszczasz Order i OrderItem razem w Agregacji zleceń. W ten sposób za każdym razem, gdy dodasz nowy OrderItem, należy go dodać za pomocą obiektu Order. Tam możesz sprawdzić całkowitą cenę i upewnić się, że nie przekracza 500 USD. Jeśli nie masz takich niezmienników w swojej domenie, nie ma sensu ładować tych wszystkich obiektów razem.

Teraz, wracając do Twojego komentarza:

Jeśli masz niezmienniki, które powinny być egzekwowane, to jest w porządku, aby załadować cały agregat mimo to może mieć jakiś napowietrznych. Tak, HTTP jest bezstanowy i ładujesz cały agregat tylko po to, aby zmodyfikować jeden z jego obiektów podrzędnych, a następnie go wyrzucić. W porządku. Najważniejsze tutaj jest to, że egzekwujesz swoje niezmienniki. Właśnie do tego służy DDD.

Celem DDD jest przechwytywanie wszystkich logik biznesowych w Twojej domenie.Zdecydowanie można osiągnąć lepszą wydajność, jeśli nie trzeba ładować całego agregatu, ale jak wymusić swoje niezmienniki? Najprawdopodobniej będziesz musiał to zrobić w swojej procedurze przechowywanej. Tak, działa i jest szybki, ale zajmowanie się logiką biznesową w procedurach przechowywanych podczas konserwacji to koszmar. Właśnie dlatego DDD ewoluowała. Możesz więc modelować swoje wymagania biznesowe, używając języków/narzędzi zorientowanych obiektowo, aby łatwiej je było zrozumieć i zmodyfikować.

Pamiętaj, DDD to świetne podejście, ale nie dla wszystkich typów projektów. Jeśli masz do czynienia z projektem, w którym istnieje wiele logiki biznesowej, a szanse ich zmiany ze względu na charakter firmy są wysokie, powinieneś użyć DDD. Jednakże, jeśli twój projekt jest bardziej "czytać coś/pisać coś" bez dużej logiki biznesowej, używanie DDD to ból głowy. Możesz po prostu użyć LINQ do SQL (lub SqlDataAdapters) i wysłać swoje obiekty do swoich widoków. Nawet nie trzeba się martwić o znalezienie podmiotów, wartość obiektów, kruszywa komór itd

Hope this helps,

Mosh