Cześć, bardzo fajny temat. Szkoda, że tak rzadko spotykany w firmach ;] Mam tylko jedno ale! Mówisz, że używasz zamiennie słów "bounded context" oraz moduł, i tutaj miałem lekki red alert w głowie, bo zazwyczaj w ramach jednego bounded contextu możemy mieć wszak wiele modułów które rozumieją ten wycinek aplikacji, niejaką granicę lingiwstyczną i odpowiedzialność zmapowanej subdomeny (jeżeli jest 1:1, bo to też nie zawsze). Przykład: Moduły o małej granulacji o nazwie Fast-Checkout oraz Checkout mogą żyć w subdomenie koszyka, moduły o dużej granulacji o nazwie BookReservation oraz BookReturnment mogą żyć w subdomenie jakiegoś działu ksiąg. Wtedy budowanie mapy kontekstów między subdomeną (BC) koszyk a ksiąg (BC) miałoby sens, czy to jakaś forma relacji, czy po prostu seperate ways by podkreślić że nie mogą se sobą te dwa bounded konteksty rozmawiać i jest to zabieg celowy
Masz rację 😎 Używałem tego zamiennie w celach czysto skrótowych, by nie wydłużać filmu, by nie wchodzić w rozważania czym jest BC a czym moduł, bo film musiałby być dwa razy dłuższy 😄
6:30 Dlaczego tutaj jest oznaczenie OHS przy module "Order"? Nie powinno ono być przy module "Order Return"? Czy może po prostu OHS, czyli moduł wystawiający API, może być zarówno po stronie Upstream jak i Downstream?
Najpierw musimy zdefiniować kto z kim rozmawia, potem co jeden potrzebuje od drugiego, a na końcu w jaki sposób to zaimplementować. OHS jest właśnie tą implementacją. Zwroty potrzebują informacji z Zamówień o tym czy dane zamówienie które klient chce anulować w ogóle istnieje w systemie. OHS jest tutaj właśnie pewnym API, udostępnianym na zewnątrz przez Zamówienia. Czyli to Zamówienia pozwalają innym pytać o dane. Dlatego Zamówienia są niżej, a Zwroty powyżej - bo to Zwroty pytają się Zamówień o dane. Mapa kontekstów z nagrania jest moją interpretacją. Zwroty są wyżej niż Zamówienia ponieważ relacja jest właśnie w tę stronę. Wiele źródeł OHS mówi o tym, że do OHS jest "hostem" lub "suplierem" a wszystko co używa tego OHS jest "comsumerem". Mimo to dla mnie ważna była relacja na diagramie.
Super temat, dzięki 😀
Cześć, bardzo fajny temat. Szkoda, że tak rzadko spotykany w firmach ;]
Mam tylko jedno ale!
Mówisz, że używasz zamiennie słów "bounded context" oraz moduł, i tutaj miałem lekki red alert w głowie, bo zazwyczaj w ramach jednego bounded contextu możemy mieć wszak wiele modułów które rozumieją ten wycinek aplikacji, niejaką granicę lingiwstyczną i odpowiedzialność zmapowanej subdomeny (jeżeli jest 1:1, bo to też nie zawsze).
Przykład: Moduły o małej granulacji o nazwie Fast-Checkout oraz Checkout mogą żyć w subdomenie koszyka, moduły o dużej granulacji o nazwie BookReservation oraz BookReturnment mogą żyć w subdomenie jakiegoś działu ksiąg.
Wtedy budowanie mapy kontekstów między subdomeną (BC) koszyk a ksiąg (BC) miałoby sens, czy to jakaś forma relacji, czy po prostu seperate ways by podkreślić że nie mogą se sobą te dwa bounded konteksty rozmawiać i jest to zabieg celowy
Masz rację 😎 Używałem tego zamiennie w celach czysto skrótowych, by nie wydłużać filmu, by nie wchodzić w rozważania czym jest BC a czym moduł, bo film musiałby być dwa razy dłuższy 😄
6:30
Dlaczego tutaj jest oznaczenie OHS przy module "Order"? Nie powinno ono być przy module "Order Return"?
Czy może po prostu OHS, czyli moduł wystawiający API, może być zarówno po stronie Upstream jak i Downstream?
Najpierw musimy zdefiniować kto z kim rozmawia, potem co jeden potrzebuje od drugiego, a na końcu w jaki sposób to zaimplementować. OHS jest właśnie tą implementacją. Zwroty potrzebują informacji z Zamówień o tym czy dane zamówienie które klient chce anulować w ogóle istnieje w systemie. OHS jest tutaj właśnie pewnym API, udostępnianym na zewnątrz przez Zamówienia. Czyli to Zamówienia pozwalają innym pytać o dane. Dlatego Zamówienia są niżej, a Zwroty powyżej - bo to Zwroty pytają się Zamówień o dane.
Mapa kontekstów z nagrania jest moją interpretacją. Zwroty są wyżej niż Zamówienia ponieważ relacja jest właśnie w tę stronę. Wiele źródeł OHS mówi o tym, że do OHS jest "hostem" lub "suplierem" a wszystko co używa tego OHS jest "comsumerem". Mimo to dla mnie ważna była relacja na diagramie.
@@adambanaszkiewicz Dzięki za wyjaśnienie :)
Oooo PHP :D
Skont wiesz?! :D
@@adambanaszkiewicz Po deptracu, ale w moim serduszku też gości PHP i za to poleciała łapka w górę :D
@@kosaa03 Dzięki :)