Wprowadzenie do Domain Driven Design: Walidowanie granic kontekstów

0:02W poprzednim materiale mówiliśmy o tym, czym są bandery, konteksty

0:06i czym jest kontekst schizofreniczny i jednym z przejawów

0:11tego, że powstaje kontekst historyczny, jest to, że mamy źle zwariowane granice

0:16kontekstów, czyli źle określone granice.

0:19I w tej lekcji skupimy się nad tym, jakie czynniki albo jakie metody możemy

0:24wykorzystać, żeby te granice kontekstów dobrze definiować.

0:28Granice kontekstów są o tyle ważne, że jeśli mamy dobrze wydzielony bandit

0:32kontekst, to łatwo jest nam Zenka postulować w nim logikę biznesową i

0:38trzymać straż tych nie zmienników biznesowych, które zawierają

0:41się w tym Bandit kontekście.

0:43I pierwszą z takich metodologii rozpoznawania valid owania granic

0:48kontekstów w Domain Driven Design jest sprawdzanie autonomii kontekstów.

0:54Musimy popatrzeć na nasze konteksty, które mamy już wydzielone, albo te, które chcemy

0:59wydzielić pod kątem ich autonomii, w jakim zakresie dany kontekst jest autonomiczny.

1:05Dobrym przykładem jest tutaj e-commerce, gdzie możemy mieć context inventory,

1:10magazynowy, kontekst invisible, fakturowanie.

1:14I te konteksty są w dużej mierze autonomiczne.

1:18One się nie przenikają w żaden sposób.

1:21Faktura, żeby wystawić fakturę za jakiś zakup nie musi wiedzieć nic na temat

1:27stanu magazynowego danego produktu.

1:29Zakup już się dokonał.

1:31Tak samo magazyn zarządzając swoimi zasobami nie ma żadnego wpływu na to,

1:36w jaki sposób numerów jemy fakturę.

1:38Mówimy wtedy, że te dwa konteksty są autonomiczne.

1:41Wszelkie operacje, jakie w nich zachodzą, wszelkie procesy biznesowe

1:46zachodzą wewnątrz tych kontekstów bez konieczności interakcji

1:50z innym kontekstem.

1:52Konteksty są autonomiczne, więc patrząc na nasz kod, w którym mamy te konteksty

1:58cieszące się dużą autonomią, zarządzające procesami biznesowymi wewnątrz siebie,

2:03mówimy wtedy, że granice naszych kontaktów są dobrze wyznaczone.

2:08Oczywiście te granice nie muszą być stałe raz na zawsze.

2:12Konteksty ewoluują tak, jak ewoluują też reguły biznesowe.

2:16Świat biznesu się zmienia.

2:18Świat naszych klientów, klientów, którzy korzystają z systemów, z aplikacji się

2:22zmienia, więc te granice mogą być płynne.

2:26Tak samo autonomia naszych kontekstów w trakcie

2:30trwania w trakcie wykorzystywania systemu może być płynna.

2:34Ale to jest pierwszy punkt, pierwszy punkt, na który trzeba zwrócić uwagę

2:37przy realizowaniu granic kontekstów.

2:39To jest ich autonomia.

2:41Punkt numer dwa to jest liczba zaangażowanych kontekstów w

2:45daną operację logiczną czy proces biznesowy, w zależności od tego.

2:50Im więcej kontekstów będzie zaangażowanych w jakiś proces biznesowy np.

2:56trzymajmy się tego przykładu z eCommerce.

2:58Wystawienia faktury.

3:00Będzie to oznaczało, że te granice nie są dobrze wyznaczone.

3:04Dobrym znakiem dobrego wyznaczania granic band kontekstów będzie to, jeśli nasz

3:10proces biznesowy korzysta z możliwie najmniejszej ilości kontekstów, które w

3:15dodatku będą jeszcze trzymać totalnie odrębną część logiki

3:20biznesowej, więc liczba kontekstów operacji biznesowej będzie nam mówić o

3:25tym, czy granice są wyznaczone dobrze czy źle.

3:29I można przyjąć taki współczynnik, że im mniej mamy kontekstów zaangażowanych

3:34w jakąś operację, tym lepiej.

3:36Te granice mamy wyznaczone.

3:38Kolejna metoda to zwracanie uwagi na informacje, które zmieniają się razem.

3:45Jeśli zmieniamy np.

3:46cenę produktu, to ta cena zmieni nam się w magazynie, ale

3:51nie zmieni nam się na wystawionej już fakturze, więc te dwa konteksty

3:54będą oddzielone od siebie.

3:58Informacje nie będą się zmieniać razem w tych dwóch kontekstach.

4:02Jeśli informacje w jakimś obiekcie, w jakiejś tabeli, bazy danych zmieniają się

4:06razem Jednocześnie to jest dobry znak na to, że powinna ta część procesu być

4:13Zenka postulowana w band and Context.

4:16Więc mamy informacje zmieniające się razem i idąc dalej będziemy mieć

4:20informacje, które będą używane razem.

4:23Jeżeli odczytujemy te same informacje z różnych tabel do wykonania

4:28tego samego procesu biznesowego.

4:30Tu mamy z kolei znak, że te informacje powinny znaleźć się w jednym kontekście.

4:35Jeśli mamy informacje, które musimy odczytać z kilku kontekstów, będzie to

4:39oznaczało, że nasze granice nie są dobrze wyznaczone.

4:43I kolejna metoda to jest odpowiedzialność kontekstu.

4:46To ma wiele wspólnego z tym pierwszym punktem, z autonomią.

4:49Natomiast tutaj mamy odpowiedzialność za zmiany, odpowiedzialność za operacje

4:53logiczne, jeśli nasz kontekst jest odpowiedzialny za zbyt wiele rzeczy, zbyt

4:57wiele procesów biznesowych, to może być znak, że ten kontekst jest

5:01zbyt duży i powinien być podzielony na mniejsze bandery konteksty.

5:05To będzie znak, że ten kontekst jest zbyt duży i powinien być podzielony

5:08na mniejsze bandery konteksty.

5:10Więc mamy tutaj odpowiedzialność kontekstu.

5:13Następną rzeczą będą integracje.

5:15Spójrzmy na integrację, z jakimi ma do czynienia nasz bandery context.

5:20Mogą to być integracje zewnętrzne z jakimiś zewnętrznymi usługami,

5:23zewnętrznymi serwisami, ale też wewnętrzne integracje z

5:26innymi kontekstami w naszym systemie.

5:29I tutaj też, jeśli mamy jakąś integracje, która będzie

5:34wykorzystywana w wielu kontekstach, to może być znak, że te konteksty zostały

5:39wyznaczone niepoprawnie i może powinny być połączone w jeden kontekst, który będzie

5:43korzystał z tej jednej integracji w jednym miejscu.

5:46Więc warto spojrzeć też na ilość integracji w naszych procesach.

5:52No i wreszcie będziemy mieć jeszcze jedno źródło prawdy.

5:55Jeśli mamy informacje, które się zmieniają razem, informacje, które używane są razem,

5:59możemy mieć też źródło prawdy.

6:01Czy kontekst jest jedynym źródłem prawdy dla jakiegoś procesu biznesowego,

6:05dla jakichś danych biznesowych?

6:07Jeśli nie jest, to znaczy, że granica mogła nie zostać wyznaczona odpowiednio.

6:13Będziemy dążyć do tego w naszym kodzie przy projektowaniu Domain Driven Design,

6:17żeby kontekst mógł być możliwie jak najbliżej źródła prawdy, żeby on był tym

6:23jednym źródłem prawdy dla procesu biznesowego.

6:26No i na koniec mamy coś takiego, co można określić jako

6:30wymagania bez sensu, bezsensu, nielogiczne wymagania anty

6:34anty wymagania nie biznesowe Wymagania.

6:36Różne pojęcia spotkasz w literaturze.

6:39Są to takie wymagania, które z punktu widzenia różnych kontekstów mogą

6:42się wykluczać lub będą bezsensu.

6:45Przykładem takiego wymagania bezsensu może być to, o czym mówiliśmy wcześniej w

6:49e-commerce, gdzie będzie takie wymaganie, że faktura nie

6:54może być wystawiona za produkt, który wcześniej nie znalazł się w magazynie,

6:58a magazyn może mieć z kolei wymaganie, że nie może przyjąć produktu

7:05do swojego inventory.

7:06Do magazynu takiego produktu, za który nie ma wystawionej faktury,

7:10mamy sprzeczne wymagania.

7:11To oczywiście bezsensu, więc łatwo wyłapać takie błędy logiczne.

7:15W takich bardzo modelowych procesach natomiast zdarzą się takie systemy, w

7:20których te błędy logiczne czy anty wymagania będą trudne do wyłapania.

7:24Dlatego wymaga to głębokiej analizy i dużego pochylenia się nad

7:29komunikacją między biznesem.

7:31Żeby dobrze zrozumieć wszelkie funkcjonalności i wymagania

7:34biznesowe, które przychodzą do zespołu programistycznego.

7:39Aby te anty wymagania mogły być wyłapane i konteksty mogły zostać dobrze wydzielone,

7:44więc mamy kilka punktów, kilka metod, które pomagają nam wydzielić

7:47granice, wariować granice kontekstów.

7:49Ale na koniec chcę, żebyś pamiętał pamiętała o tej jednej rzeczy że granice

7:53nie są stałe raz na zawsze, bo biznes się zmienia, ewoluuje, więc te

7:57granice też mogą być elastyczne.

7:59Dlatego zawsze trzeba mieć w głowie te kilka metod, które możemy wykorzystywać,

8:03żeby te nasze granice odświeżać, żeby one ewoluowały, aby konteksty

8:08były wyznaczone prawidłowo.