Wątek przeniesiony 2019-11-13 18:10 z przez Patryk27.

DDD - optymalizacja operacji na dużych kolekcjach wchodzących w skład agregatu i paginacja

Odpowiedz Nowy wątek
2019-11-13 14:46
0

Edycja: Byłbym wdzięczny o przeniesienie do forum 'Inżynieria oprogramowania'

Witam serdecznie, moje pytanie będzie się odnosić ogólnie do DDD ale posłużę się przykładem, aby łatwiej pokazać o co mi chodzi.
Załóżmy, że chcemy zaprojektować model forum, w którego skład wchodzi następujący agregat:

Wątek << Aggregate Root >>
Post << Entity >>

Wydaje się logiczne, że post nie ma globalnej tożsamości więc będzie wchodził w skład wątku.
W tym momencie wszystko wygląda w porządku, dopóki wielkość kolekcji postów nie będzie miała dużych rozmiarów.

I tutaj moje pytanie - jak powinna wyglądać poprawna paginacja postów. Nie chcę dodawać do wątku metod typu getPosts(int page), które nie mają nic wspólnego z domeną a tworzenie repozytorium postów przeczy idei agregatu.

Moje następne pytanie - zakładamy, że aplikacja ma możliwość operacji na pojedynczych postach, typu: edycja postu, polubienie postu. W sytuacji gdy kolekcja postów danego wątku jest bardzo duża za każdym razem muszę pobrać ją całą i dopiero wtedy wykonać operację na danym poście. Jak poprawnie zoptymalizować takie operację?

Pozdrawiam.

edytowany 3x, ostatnio: anon, 2019-11-13 14:50

Pozostało 580 znaków

2019-11-13 14:50
0

A reguły, że coś ma być na N-tej stronie to skąd masz?

Pozostało 580 znaków

2019-11-13 14:57
0

A może Wątek jest tylko view modelem zasilanym z Postów, które są agregatami? Można to różnie rozegrać, na pewno nie sugeruj się tym, jak to wyglada na UI.

Pozostało 580 znaków

2019-11-13 14:58
0
yarel napisał(a):

A reguły, że coś ma być na N-tej stronie to skąd masz?

Posty sortowane są według daty utworzenia, to co ma być na której stronie określa dana implementacja repozytorium, aplikacja tylko prosi o numer strony i jej wielkość

Pozostało 580 znaków

2019-11-13 14:59
0

Rootem agregatu może być równie dobrze para: identyfikator wątku + numer strony które razem stworzą unikalny klucz podstawowy. W ten sposób unikasz metody getPosts(int page)


edytowany 1x, ostatnio: TomRZ, 2019-11-13 15:00

Pozostało 580 znaków

2019-11-13 14:59
0

https://dddcommunity.org/library/vernon_2011/

Te strony to taki średni pomysł. A jak ktoś skasuje post, to należy zmieniać wszystkie klucze?

edytowany 1x, ostatnio: nalik, 2019-11-13 15:03

Pozostało 580 znaków

2019-11-13 15:00
0
Charles_Ray napisał(a):

A może Wątek jest tylko view modelem zasilanym z Postów, które są agregatami? Można to różnie rozegrać, na pewno nie sugeruj się tym, jak to wyglada na UI.

Tzn, model forum zakłada istnienie czegoś takiego jak wątek, który ma dane utworzenia właściciela itd, więc wydaje mi się, że powinien istnieć jako osobny agregat

TomRZ napisał(a):

Rootem agregatu może być równie dobrze para: identyfikator wątku + numer strony które razem stworzą unikalny klucz podstawowy. W ten sposób unikasz metody getPosts(int page)

Jeśli dobrze zrozumiałem to każda strona będzie miała osobną tożsamość, gdzie w tym wypadku będą istotne informacje o wątku jako całości? Nie wydaje mi się to dobre rozwiązanie ale może źle zrozumiałem

edytowany 1x, ostatnio: anon, 2019-11-13 15:11

Pozostało 580 znaków

2019-11-13 15:25
0
anon napisał(a):
yarel napisał(a):

A reguły, że coś ma być na N-tej stronie to skąd masz?

Posty sortowane są według daty utworzenia, to co ma być na której stronie określa dana implementacja repozytorium, aplikacja tylko prosi o numer strony i jej wielkość

A czemu nie sortowanie po długości posta? Niech zgadnę, pewnie masz regułę biznesową, która mówi "porządek taki i nie inny" i jakąś wielkość strony.
Reguły biznesowe nie są elementem Twojego modelu?

Jeśli repo zwraca Ci content dla określonej strony, to co w tym złego? Zwalasz robotę na silnik na którym pracuje repozytorium (żeby nie pisać baza relacyjna ;) ) Co tu optymalizować?

Pozostało 580 znaków

2019-11-13 15:41
0
yarel napisał(a):
anon napisał(a):
yarel napisał(a):

A reguły, że coś ma być na N-tej stronie to skąd masz?

Posty sortowane są według daty utworzenia, to co ma być na której stronie określa dana implementacja repozytorium, aplikacja tylko prosi o numer strony i jej wielkość

A czemu nie sortowanie po długości posta? Niech zgadnę, pewnie masz regułę biznesową, która mówi "porządek taki i nie inny" i jakąś wielkość strony.
Reguły biznesowe nie są elementem Twojego modelu?

Jeśli repo zwraca Ci content dla określonej strony, to co w tym złego? Zwalasz robotę na silnik na którym pracuje repozytorium (żeby nie pisać baza relacyjna ;) ) Co tu optymalizować?

Moje pytanie dotyczy stricte DDD, napisałem wyżej, że wątek jest korzeniem agregatu przez który odwołuje się do postów, nie wiem do czego nawiązujesz pisząc, że zwalam robotę na repozytorium. Wątek i post stanowią całość, jako że wątek jest korzeniem do jego zawartości odnoszę się tylko za jego pomocą, co za tym idzie posty nie mają osobnego repozytorium - są niewidoczne z poza agregatu.

Niech zgadnę, pewnie masz regułę biznesową, która mówi "porządek taki i nie inny" i jakąś wielkość strony.
Reguły biznesowe nie są elementem Twojego modelu?

Strona i jej wielkość nie są elementami domeny tylko aplikacji, porządek jest i jak wyżej napisałem stanowi część modelu

edytowany 1x, ostatnio: anon, 2019-11-13 15:41

Pozostało 580 znaków

2019-11-13 16:21
0

Pisząc o zwalaniu pracy na repozytorium, mam na myśli to, że ta cała praca zostanie wykonana po stronie silnika, na którym jest repozytorium (w domyśle: baza danych). Nie będzie przesyłania całości danych do aplikacji, która miałaby je sobie obrobić. Osobiście nie widzę nic złego w takim "getPage" w modelu, a to dlatego że:

Masz wymagania odnośnie prezentacji albo nie masz wymagań.

  Nie masz wymagań 
    -> nie ma co roztrząsać, paginacje nie są biznesowi potrzebne, a robiąc je generujesz problem, gdzie tu zysk i dla kogo?

  Masz wymagania 
    -> robisz model
        -> Model wspiera wymagania -> klawo
        -> Model nie wspiera wymagań -> czy nie trzeba czegoś zmienić? 

Możesz rozważyć różne modele i sprawdzić "mentalnie" jak będą się zachowywać:
screenshot-20191113161649.png

Pozostało 580 znaków

2019-11-13 16:34
0
TomRZ napisał(a):

Rootem agregatu może być równie dobrze para: identyfikator wątku + numer strony które razem stworzą unikalny klucz podstawowy. W ten sposób unikasz metody getPosts(int page)

Jeśli dobrze zrozumiałem to każda strona będzie miała osobną tożsamość, gdzie w tym wypadku będą istotne informacje o wątku jako całości? Nie wydaje mi się to dobre rozwiązanie ale może źle zrozumiałem

Możesz stworzyć dwa agregaty - jeden do analizy całościowej, a drugi do stronnicowania.

Obydwa będą miały różny root id / pk - bo ten do stronnicowania będzie złożony z id wątku + numer strony a całościowy tyko id wątku.


edytowany 1x, ostatnio: TomRZ, 2019-11-13 16:51

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0