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.