Możesz wyświetlić poziom zapasów na stronie internetowej lub możesz wyświetlić numer wydania zapasów w magazynie (wyobraź sobie, że twoje zapasy to książki, czasopisma itp.). Te informacje pochodzą z domeny zasobów reklamowych.
Najważniejszą rzeczą, na którą należy zwrócić uwagę w tym momencie, jest to, że mówisz o widoku, co oznacza, że używanie przestarzałych danych jest dopuszczalne.
To powiedziawszy, nie musisz wchodzić w interakcje z agregatami (które są odpowiedzialne za zapobieganie naruszeniom niezmiennika biznesowego), ale z reprezentacją najnowszej kopii stanu agregacji.
Tak więc normalnie spodziewałbym się uruchomienia zapytania względem katalogu produktów i innego uruchomienia w wykazie oraz czegoś, co połączy te dwa elementy w DTO, którego potrzebujesz do obsługi tego widoku.
Czy załadować zarówno domenę produktu, jak i agregaty domeny zasobów reklamowych?
Więc to blisko . Nie musimy ładować agregatów, ponieważ niczego nie zmienimy. Ale potrzebujemy ich państwa; żebyśmy mogli to załadować. To powiedziawszy, normalnie oczekiwałbym, że te dwie domeny będą działać w różnych procesach. Dlatego dzwonilibyśmy do obu, nie ładując obu.
Czy zachowałbyś jakieś właściwości w jednostce domeny produktu dla numeru w magazynie i edycji w magazynie, a następnie używałeś zdarzeń domeny, aby je zaktualizować, gdy jednostka zapasów jest aktualizowana?
„Nie przekraczaj strumieni. Byłoby źle”.
Wykorzystywanie zdarzeń do koordynowania informacji w różnych kontekstach domen: świetny pomysł. Wprowadzanie pojęć należących do jednej domeny do drugiej: przeciwieństwo świetnego pomysłu, poza tym bardziej.
Chcesz utrzymać domeny w czystości. Do aplikacji , które oddziałują z domenami, to nie jest tak ważne. Na przykład uzasadnione jest, aby aplikacja Inventory wywoływała usługę w aplikacji produktu w celu zapytania niektórych koncepcji specyficznych dla produktu, które można dodać do widoku. Lub odwrotnie.
Nie znam żadnego powodu, dla którego jedna aplikacja musi być ograniczona do jednej domeny. Tak długo, jak istnieje jedno źródło prawdy, możesz rozpowszechniać transakcje w dowolny sposób.
Ale żeby to przemyśleć, w powyższym przykładzie otrzymalibyśmy potencjalnie 2 tabele DB dla katalogu produktów i spisu produktów. Czy używamy w nich tego samego identyfikatora, ponieważ jest to ten sam produkt.
To byłby łatwy sposób. Mówiąc szerzej, używasz tego samego identyfikatora, ponieważ istota świata rzeczywistego jest taka sama; dwa różne konteksty ograniczone modelują tę jednostkę inaczej, ale model nie jest bytem świata rzeczywistego.
Jeśli to nie zadziała, będziesz potrzebować zapytania, aby wypełnić lukę. Myślę, że najczęstszą odmianą tego jest to, że nowszy byt zachowuje identyfikator starszego bytu. Zobaczysz to również w ciągu jednego BC: po zatwierdzeniu kandydaci zostaną klientami. Jest to inny agregat (stan związany z klientem podlega innemu niezmiennikowi niż stan wnioskodawcy); więc jeśli twoja warstwa trwałości używa strumieni zdarzeń, strumień nowego agregatu będzie wymagał innego identyfikatora. Tak więc gdzieś będzie informacja, że „ten wnioskodawca został tym klientem”.
Czy możemy użyć 1 tabeli i 1 wiersza tabeli dla danych i po prostu zmapować odpowiednie dane na właściwości agregujące?
TAK! Nie rób tego. Dodajesz niezgodność transakcji bez żadnego uzasadnienia biznesowego.
Myślę, że twoje pytanie naprawdę wymaga 2 ortogonalnych zestawów opcji -
Czy ładujesz dwa obiekty i prezentujesz ich dane razem, czy ładujesz 1 obiekt zawierający wszystko, co chcesz?
Czy używasz agregatów do wyświetlania rzeczy, czy czegoś innego?
Jeśli wierzysz w podejście CQRS, okazuje się, że agregaty mogą nie być najlepszym wyborem dla odczytów. Za każdym razem, gdy ładujesz agregat, czy chcesz wyświetlać jego dane, czy go modyfikować, dodajesz współbieżność i rywalizację do swojego systemu. Ponadto agregaty są potencjalnie większe i wolniej się ładują niż w przypadku korzystania z modeli odczytu ad-hoc dostosowanych do wyświetlania.
Rozwiązanie a) z twojego Q wydaje się podlegać wielu z tych pułapek. Opcja b) może być poprawna, ale użyłbym jej tylko wtedy, gdy dane z
InventoryManagementBC są potrzebne do wymuszenia niezmienników podczas mutacjiProductagregacji. Lepiej, jeśli agregat zawiera wszystkie dane potrzebne do sprawdzenia reguł biznesowych po modyfikacji, ale po stronie odczytu mogą siedzieć w dowolnym miejscu.Jeśli chodzi o dane, powszechnym zaleceniem jest nadanie ograniczonym kontekstom własnej bazy danych (ze względu na możliwość wdrożenia i ze względu na SoC). Prawdopodobnie będziesz musiał użyć tych samych identyfikatorów, jeśli chcesz dopasować produkty między dwoma BC.
O interakcjach między BC, możesz także zajrzeć na /programming/16713041/communicating-between-two-bounded-contexts-in-ddd
źródło
DDD jest przeznaczony do aplikacji, w których logika biznesowa jest złożona. „wydrukuj coś” nie jest złożoną logiką biznesową. To wcale nie jest logika biznesowa.
Jeśli logika biznesowa w jednym kontekście potrzebuje pewnych informacji, aby poprawnie obsłużyć pewien przypadek użycia, to informacja ta jest częścią tego kontekstu. Pomysł, że jeden ograniczony kontekst może potrzebować informacji dostępnych w innym ograniczonym kontekście, nie ma sensu, ponieważ ograniczony kontekst zawiera wszystkie potrzebne informacje.
źródło
Z mojego punktu widzenia istnieją różne definicje „produktu” - każdy kontekst ograniczający ma własną definicję domeny „produkt”:
Oprócz tego dodałbym dodatkowy Kontekst ograniczający sklep z własną definicją produktu (odpowiednia kombinacja domen produktów innych kontekstów ograniczających).
Produkt sklepowy miałby „obraz i tekst opisu” z treści i dostępności z „Zapasów”, ale nie „sprzedawca produktu” z zapasów.
Ten dodatkowy kontekst ograniczający do sklepu zależy od zawartości ograniczającej, zawartości, zapasów, ceny
źródło