DDD: czy właściwe jest, aby agregat główny zawierał odwołanie do innego agregatu głównego?

Czy w przypadku projektowania opartego na domenie (DDD) właściwe jest, aby agregacja główna zawierała odwołanie do encji wewnętrznej, która akurat jest jednostką root na oddzielnej agregacji?

Uważam, że nie jest to poprawne, głównie z powodu tej reguły niebieskiej księgi :

Nic poza granicą AGREGACJI nie może zawierać odniesienia do czegokolwiek w środku, z wyjątkiem ENTITY root. Podstawowy ENTITY może przekazywać odniesienia do wewnętrznych PODMIOTÓW innym obiektom, ale te obiekty mogą z nich korzystać tylko przejściowo i nie mogą trzymać się odwołania. Rdzeń może przekazać kopię WARTOŚCIOWEGO OBIEKTU innemu obiektowi i nie ma znaczenia, co się z nim stanie, ponieważ jest to po prostu WARTOŚĆ i nie będzie już miał żadnego związku z AGREGATEM.

Jeśli agregat główny zawiera odniesienie do innego agregatu głównego, granica tego pierwszego zostaje naruszona, a cała koncepcja agregatu jest uszkodzona, więc uważam, że jeśli agregat główny wygląda na potrzebę posiadania odwołania do innego agregatu głównego, to potrzebuję aby utworzyć inny byt, który prawdopodobnie będzie miał część tych samych członków, co inny byt główny, ale nie będzie miał globalnej tożsamości, ponieważ ta inna reguła w książce stanowi:

PODMIOTY Root mają globalną tożsamość. PODMIOTY wewnątrz granicy mają tożsamość lokalną, unikalną tylko w AGREGATIE.

Wierzę, że byłby to właściwy sposób, ale ponieważ wydaje się powtarzalny i zbędny (po zdjęciu z kontekstu DDD, z czystym OOP), proszę o jakieś informacje zwrotne.

Być może interpretujesz książkę. Mówi w zasadzie: cokolwiek poza agregatem nie może zawierać odniesienia do niczego w nim, z wyjątkiem katalogu głównego. Dlatego trzymanie odwołania do katalogu głównego jest uzasadnione. Trzymanie odniesienia do katalogu głównego nie oznacza, że ​​jest to część twojego agregatu i że możesz kontrolować jego niezmienniki. Zachowuje własne niezmienniki i autonomię.

Jednak,

• Powszechnie przyjętą dobrą praktyką jest odwoływanie się do AR poprzez przechowywanie jego identyfikatora, a nie pełnego odniesienia.
• Bardziej nowoczesne podejścia do projektowania agregatów (patrz Czerwona Księga ) zalecają czystsze rozdzielenie agregatów. Transakcja biznesowa powinna zmieniać tylko stan pojedynczego agregatu. Przy takim założeniu potrzeba przechowywania odniesienia do innego agregatu ma tendencję do znikania, ponieważ nie zamierzasz modyfikować 2 agregatów w tym samym czasie.

czy właściwe jest, aby agregacja główna zawierała odwołanie do encji wewnętrznej, która jest akcją root na oddzielnej agregacji?

To się nigdy nie zdarza. Obiekt wartości może być częścią wielu agregatów, ale nie może być jednostką. Powodem jest to, że nic nie uniemożliwiłoby ci współużytkowania tej samej instancji encji między agregatami. Powiedzmy, że instancja encji E należy do obu instancji zagregowanych A i B. Ponieważ DDD zakłada, że ​​Aggregate jest punktem wejściowym, będziesz w stanie załadować A, zmodyfikować encję E, jednocześnie cicho naruszając niezmienniki z B (że nie załadowałeś).

Zobacz odpowiedź Grega Younga tutaj: http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html

Twój zagregowany obiekt główny powinien (ogólnie) mieć tylko właściwości, które są częścią jego domeny.

Jeśli masz obiekt AR z właściwością, której nie ma w agregacie, natychmiast pojawia się pytanie. 'Dlaczego nie?'

Możesz dodać identyfikator innego obiektu? Lub wstrzyknąć repozytorium?

Ale wygląda na to, że powinieneś dodać usługę między domenami, która odwołuje się zarówno do obiektów root, jak i wykonuje wymaganą logikę