Pytanie Jak radzisz sobie z powiązaniami między agregatami w DDD?


Nadal pakuję głowę wokół DDD, a jednym z przeszkód, z jakimi się zetknąłem, jest jak radzić sobie z powiązaniami pomiędzy oddzielnymi agregatami. Załóżmy, że mam jeden agregat obejmujący klientów i inne przesyłki zawierające.

Ze względów biznesowych przesyłki są ich własnymi zbiorami, a mimo to muszą być wyraźnie powiązane z klientami. Czy mój podmiot domeny klienta powinien mieć listę przesyłek? Jeśli tak, jak zapełnić tę listę na poziomie repozytorium - biorąc pod uwagę, czy będę miał CustomerRepository i ShipmentRepository (jedno transakcje repo na agregat)?

Mówię "stowarzyszenie", a nie "związek", ponieważ chcę podkreślić, że jest to decyzja domeny, a nie infrastruktura - najpierw projektuję system z modelu.

Edycja: Wiem, że nie muszę modelować tabel bezpośrednio do obiektów - to jest powód, dla którego najpierw projektuję model. W tym momencie w ogóle nie interesuje mnie baza danych - tylko skojarzenia między tymi dwoma agregatami.


16
2018-02-06 20:31


pochodzenie


ddd nie jest narzędziem gnu gnu.org/software/ddd ? od kiedy ddd oznacza projektowanie sterowane przez domenę ??? - Johan
@ Johan - chwileczkę, teraz - domaindrivendesign.org - Erik Forbes
@Erik, wszystko się zmienia, a także krótkie wersje długich słów. - Johan
Tak, robią. = P - Erik Forbes


Odpowiedzi:


Nie ma powodu, dla którego ShipmentRepository nie będzie mogła gromadzić danych klientów w modelach wysyłkowych. Repozytoria nie muszą mieć mapowania 1 do 1 z tabelami.

Mam kilka repozytoriów, które łączą wiele tabel w jeden model domeny.


8
2018-02-06 21:10



Więc czy mówisz, że to w porządku, mieć te same dokładne dane dostępne przez dwa różne zagregowane korzenie? - Erik Forbes


Sądzę, że są dwa poziomy odpowiedzi na to pytanie. Na jednym poziomie pytanie brzmi: w jaki sposób zapełnić relację między klientem a przesyłką. Bardzo podoba mi się semantyka "wypełnienia", w której repozytorium przesyłek może mieć wypełnienia (listy klientów, ....).

Drugi poziom to "jak obsłużyć zdenormalizowane modele domen, które są częścią DDD". A "Klient" jest prawdopodobnie najlepszym przykładem z nich wszystkich, ponieważ po prostu pojawia się w tak wielu różnych kontekstach; prawie wszystkie procesy zawierają klienta, a kontekst klienta jest zwykle bardzo zróżnicowany. W maksymalnie połowie czasu jesteś zainteresowany "zamówieniami". Gdyby moje rozumienie domeny było idealne, kiedy zaczynałem, zrobiłbym to nigdy stworzyć pojęcie domeny klienta. Ale tak nie jest, więc zawsze robię obiekt klienta. Wciąż pamiętam projekt, w którym po nim 3 lata czułem, że udało mi się stworzyć odpowiedni model domeny "Klient". ja by szukać alternatywnych i bardziej szczegółowych koncepcji, które również reprezentują klienta; PotentialCustomer, OrderingCustomer, CustomerWithOrders i prawdopodobnie kilka innych; przepraszam, imiona nie są lepsze. Potrzebuję więcej czasu na to;)


5
2018-02-06 20:54





Przesyłka ma związek z relacją wiele do jednego z Klientem. Jeśli szukasz przesyłek klienta, dodaj zapytanie do repozytorium przesyłek, które pobiera parametr klienta.

Generalnie nie tworzę związków pomiędzy jednostkami, gdy wiele stron nie jest ograniczone.


0
2018-02-10 01:25