Wyznaczenie bounded contextów

Odpowiedz Nowy wątek
2019-07-24 18:46
0

Powiedzmy, że mam typowy sklep internetowy.

1) Klient może dodawać recenzje produktów.
2) W widoku produktu wraz z każdą recenzją powinno pojawić się też imię i nazwisko autora (klienta).
3) Klient może przeglądać w osobnym widoku wszystkie swoje recenzje wraz z krótką informacją o produkcie, którego dana recenzja dotyczy.
4) Klient może uznać recenzję za pomocną lub niepomocną - wraz z recenzją powinna pojawić się informacja o tym, ilu użytkowników uznało ją za pomocną, a ilu wręcz przeciwnie - niezależnie od widoku, w którym jest wyświetlana (punkty 2 i 3).
4) Klient może oceniać produkty.
5) Wraz z produktem powinna pojawić się też średnia wszystkich ocen.
6) Klient może przeglądać w osobnym widoku wszystkie produkty, które ocenił, wraz z przyznaną oceną.

W TS miałbym klasy: User, Customer, Product, ProductReview, ProductRate, ReviewReaction. Jak będą wyglądały bounded contexty przy takich początkowych wymaganiach?

Pozostało 580 znaków

2019-07-24 22:18
1

Klasycznie jeden kontekt to user. (nieopisany).
A reszta to reszta w tym przypadku - kontekt ocen - rates. Nie widzę sensu dzielenia tego.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2019-07-25 07:08
0

Czyli byłoby tak:

  • Customer (AR)
  • Product (AR)
    • Rate (E)
  • Review (AR)
    • Reaction (E)

Wszystko to umieszczam w jednym module i dla każdego z tych agregatów tworzę osobny folder. W folderze z Review tworzę jakiś ReviewReader, który zwraca recenzje klienta. W folderze z Product tworzę ProductReader, który zwraca produkty ocenione przez klienta. Wstrzykuję potem te readery do CustomerService.

Wołam innych ludzi znających DDD: pomocy @somekind, @neves, @Aventus, @hauleth i ktokolwiek inny znający się.

edytowany 1x, ostatnio: nobody01, 2019-07-25 07:10

Pozostało 580 znaków

2019-07-25 11:58
1

Tyż jeden kontekst tylko widzę, nazwijmy go Recenzje, będzie on zawierał w sobie okrojone wersje agregatów Klienta i Produktu, zawierająca tylko informacje potrzebne na potrzeby tego modułu.


Java to taki C# tyle że z gorszą składnią.

Pozostało 580 znaków

2019-07-25 12:26
0

A konteksty Klienci i Produkty beda zawierac wlasne wersje agregatu Recenzja? Tylko ze wtedy bede musial skopiowac caly agregat Recenzja do kontekstu Produkty i kontekstu Klienci ze wzgledu na punkty 2 , 3 i 4,, bo chyba kazdy kontekst powinien miec wlasne dane potrzebne do wykonania zapytania.

Pozostało 580 znaków

2019-07-25 12:33
2

Konteksty Klient i Produkt nie mają potrzeby nic wiedzieć o kontekście Recenzji, wszystkie te podpunkty realizujesz wyłącznie w kontekście recenzji. Żeby lepiej to zobrazować wyobraź sobie w głowie, każdy z tych kontekstów jako oddzielny mikroserwis z orkiestracją po stronie przeglądarki, jak wchodzisz na stronę produktu, masz id produktu, po tym id z kontekstu produktu pobierasz wszystkie informacje o produkcie, a z kontekstu recenzji wszystkie recenzje tego produktu.


Java to taki C# tyle że z gorszą składnią.
edytowany 1x, ostatnio: neves, 2019-07-25 12:34

Pozostało 580 znaków

2019-07-25 12:43
0

Ok, a jesli mam monolit i chce utworzyc ViewModel z informacjami o produkcie i kilku najlepszych recenzjach, to jak to zrobic? W kontrolerze pobrac dane z dwoch modulow i polaczyc w jeden ViewModel?

edytowany 1x, ostatnio: nobody01, 2019-07-25 12:49

Pozostało 580 znaków

2019-07-25 18:08
0

Ja tam widzę jeden kontest Discussion

Konteksty Klient i Produkt nie mają potrzeby nic wiedzieć o kontekście Recenzji

Klient i Product to nie są żadne kontesky.

Pozostało 580 znaków

2019-07-26 08:33
0
BanBlock napisał(a):

Ja tam widzę jeden kontest Discussion

A skąd wyczarowałeś taką nazwę? Nie powinno to być zgodne z duchem "wszechobecnego języka" i jawnie nawiązywać do terminologii używanej przez "biznes", czyli po prostu "Recenzje"?

Druga wątpliwość, czy wówczas nie doprowadzi to do patologii, w postaci nazywania w kodzie, konceptów domenowych po polsku? ;) Dziwne byłoby to, że w "języku wszechobecnym" "Recenzja", zaś w kodzie "Review", "Rate", "Vote", etc. "Wszechobecny język", ale jednak nie wszędzie ? ;)

Konteksty Klient i Produkt nie mają potrzeby nic wiedzieć o kontekście Recenzji

Klient i Product to nie są żadne kontesky.

Klient i Produkt w różnych miejscach "typowego sklepu internetowego" mogą mieć różne znaczenie, więc słuszna uwaga.

Pozostało 580 znaków

2019-07-26 22:57
3

Tak naprawdę to trochę wróżenie z fusów, bo "typowych" sklepów internetowych jest cała masa a jednak się znacznie różnią. Proponowanie czegoś w tym przypadku jest trochę bez sensu nie znając szczegółów. A jeśli to co opisałeś to już wszystkie szczegóły to nie widzę potrzeby bawienia się w rozbijanie tego na siłę na konteksty. Poza tym to wygląda jak jeden kontekst (ewentualnie jak już było wspomniane wyżej User może być wyodrębniony do oddzielnego kontekstu) ponieważ te klasy wydają się spójnie powiązane. Masz jeden kontekst- Reviews/Rating/inna nazwa.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-08-01 15:00
1

Myślę, że warto było by tutaj wyznaczy je korzystając z Event Storminu. Wówczas mamy lepsze wyobrażenie o tym, jak ten system działa. Konteksty mogą się wówczas wyłonić, zwłaszcza gdy taki sobie ustalimy cel sesji.

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