Wyznaczenie bounded contextów

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).
  5. Klient może oceniać produkty.
  6. Wraz z produktem powinna pojawić się też średnia wszystkich ocen.
  7. 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?

1

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

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ę.

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.

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.

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.

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?

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.

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.

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.

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.

1

Typowe wymagania biznesowe - na tej podstawie można zidentyfikować co najwyżej view modele, czyli do kontekstów jeszcze daleko.

Pamiętaj, że biznes myśli happy pathem i gujem. Aby określić subdomeny (przestrzeń problemu), a dopiero potem konteksty (przestrzeń technicznego rozwiązania) trzeba by zadać parę pytań dotyczących zmienności i spójności danych.

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