Na podstawie Twojej terminologii zakładam, że wykonujesz DDD w oparciu o książkę Eric Evans. Wygląda na to, że masz już problem z początkową próbą modelowania i masz rację.
Wspominasz, że myślałeś o dostawcy jako Value Object ... Sugeruję, że nie jest. A Value Object jest czymś przede wszystkim identyfikowane przez jego właściwości. Na przykład data "30 września 2009 r." Jest obiektem wartości. Czemu? Ponieważ wszystkie wystąpienia daty z innym combo miesiąc/dzień/rok są różne daty. Wszystkie wystąpienia daty z tym samym combo miesiąca/dnia/roku są uważane za identyczne. Nigdy nie spieramy się z zamianą mojego "30 września 2009 r." Dla ciebie, ponieważ są one takie same :-)
Z drugiej strony, Entity jest identyfikowany przede wszystkim przez jego "ID". Na przykład konta bankowe mają identyfikatory - wszystkie mają numery kont. Jeśli w banku są dwa rachunki, każdy z 500 $, jeśli ich numery kont są różne, tak samo są. Ich właściwości (w tym przykładzie, ich równowaga) nie identyfikują ich ani nie implikują równości.Założę się, że kłócilibyśmy się nad zamianą kont bankowych, nawet gdyby ich salda były takie same :-)
Tak więc, w twoim przykładzie, rozważałbym dostawcę jako Entity, ponieważ przypuszczam, że każdy dostawca jest identyfikowany głównie przez jego identyfikator niż jego właściwości. Moja własna firma dzieli swoją nazwę z dwoma innymi na świecie - jednak nie wszystkie są wymienne.
Myślę, że twoja sugestia, że jeśli potrzebujesz widoków na CRUDing obiektu to jest to Entity prawdopodobnie jest prawdą, ale powinieneś bardziej skupić się na tym, co sprawia, że jeden obiekt różni się od innych: właściwości lub ID.
Teraz przejdź do etapu Aggregate Root, aby skoncentrować się na cyklu życia i kontroli dostępu do obiektów. Zastanów się, że mam bloga z wieloma wpisami, z których każdy ma wiele komentarzy - gdzie jest/są Aggregate Root (s)? Zacznijmy od komentarzy. Czy ma sens komentarz bez postu? Czy utworzyć komentarz, a następnie znaleźć post i dołączyć go do niego? Jeśli usuniesz wpis, czy będziesz go komentować? Sugeruję, aby jeden z postów to "Aggregate Root" z jednym "liściem" - komentarze. Rozważmy teraz samego bloga - jego relacje z postami są podobne do postów i komentarzy. To także moim zdaniem jest Aggregate Root z jednym "liście" - posty.
Na przykład, czy istnieje silna zależność między firmą a dostawcą, że jeśli usuniesz firmę (wiem, że ... prawdopodobnie masz tylko jedną instancję firmy), usuniesz również jej dostawców? Jeśli usuniesz "Starbucks" (firmę produkującą kawę w USA), czy wszyscy dostawcy ziaren kawy przestaną istnieć? Wszystko zależy od twojej domeny i aplikacji, ale sugeruję, że nie jest tak, że żaden z twoich Entities jest Aggregate Roots, a może lepszym sposobem na pomyślenie o nich jest to, że są to Rozdrażnione Korzenie, bez żadnych "liści" (nic do zagregowania). Innymi słowy, firma nie kontroluje dostępu do ani nie kontroluje cyklu życia dostawców. Ma po prostu relację jeden-do-wielu z dostawcami (lub może wiele-do-wielu).
To prowadzi nas do Repositories. A Repository służy do przechowywania i odzyskiwania Aggregate Roots. Masz dwa (technicznie rzecz biorąc, nie agregują niczego, ale jest to łatwiejsze niż powiedzenie "repozytoria przechowują zagregowane katalogi lub encje, które nie są zbiorami"), dlatego potrzebujesz dwóch: Repositories. Jeden dla firmy i jeden dla dostawców.
Mam nadzieję, że to pomoże. Być może Eric Evans czai się tutaj i powie mi, gdzie odejdę od jego paradygmatu.
Niesamowita odpowiedź! Pomogłeś zweryfikować to, o czym myślałem i wyjaśniłem o wiele więcej. Dziękuję bardzo! Zgadzam się, należy powoływać się na dostawców, o ile istnieją, ale na razie będą to dane wprowadzone przez użytkownika, bez możliwości potwierdzenia, że 2 dostawców jest takich samych. To może się zmienić w przyszłości, gdy system ewoluuje, ale na razie to jest historia. Dzięki jeszcze raz! –
Zgadzam się, że jest to świetne wyjaśnienie, bardziej pomocne niż to, co zwykle znajduje się na liście mailingowej DDD! –
Doskonała odpowiedź. Jeden głos ode mnie. –