Domain Driven Design: Praca z bazą danych

0:00Porozmawiajmy teraz o bazach danych.

0:03Baza danych i praca z bazami danych w Domain Service Design

0:06to nierzadko wielkie wyzwanie.

0:09Bo jeśli operujemy na wielu kontekstach, konieczne jest jakiś sposób izolacji

0:14warstw danych pomiędzy naszymi kontekstami.

0:18I z pomocą przychodzą tutaj różne techniki, które zostały już zdefiniowane

0:23po to, żeby ta praca z bazą danych przebiegała bez problemowo.

0:27Na początek musimy pamiętać o tym, że.

0:31każdy Context zarządza jakimś swoim pakietem danych

0:36i pierwszym najprostszym sposobem, który nam przychodzi do głowy jest po prostu

0:40stworzenie oddzielnych baz danych dla każdego kontekstu, gdzie każdy kontekst

0:45zapisuje i czyta tylko do swojej d izolowanej bazy danych, przez co mamy

0:49zapewnioną izolację i niezależność pomiędzy danymi poszczególnych kontekstów.

0:55Drugą techniką jest tworzenie różnego rodzaju skim schematów w jednej bazie

1:00danych, z czym szczególnie dobrze radzi sobie PostgreSQL.

1:04Takie oddzielne schematy dla każdego kontekstu współistnieją w jednej bazie i

1:08konteksty wiedzą, z którego schematu należy korzystać.

1:12Dla administratorów czy inżynierów ułatwia to zarządzanie, ale z drugiej strony

1:16wymaga dużej dyscypliny w izolacji, bo utrzymywanie różnych skal w jednej bazie

1:21danych jest czasami problematyczne, zwłaszcza w bardzo dużym systemie.

1:27Możemy także korzystać z widoków takich zwykłych oldskulowe tych SQL owych

1:31widoków, które wykorzystujemy do odczytu danych między

1:34kontekstami bez naruszania granic.

1:36Mamy kilka kontekstów.

1:38Przez to, żeby zapewnić tym kontekstem izolację, żeby

1:42one nie musiały odpytywać się wzajemnie.

1:45Stosujemy widoki i różne konteksty.

1:48Mają swoje zdefiniowane widoki.

1:50One są utrzymywane często na poziomie kodu, zdefiniowane w kodzie aplikacji I

1:55te konteksty z tych widoków korzystają i czytają dane, przez co mamy

1:59zapewnioną konsystencję, izolację.

2:02Możemy także pokusić się o pracę z eventami Domain Driven Design.

2:06Bardzo mocny. Nacisk.

2:08Kładzie na to, żebyśmy pracowali z eventami i tutaj możemy mieć

2:14zastosowaną technikę, event konsystencji z eventami, gdzie będziemy synchronizować

2:19sobie dane pomiędzy kontekstami za pomocą opublikowanych zdarzeń domenowych.

2:24Uzyskamy tutaj pewną asynchronicznie, ale też i odporność na błędy.

2:28Możemy też stosować table prefix link Co to jest table fixing albo dodawanie sobie

2:33prefiksu charakterystycznego dla kontekstu do nazwy tabeli.

2:37Więc mamy jedną tabelę, jedną z kimś, ale dodajemy sobie prefiksy, czyli np.

2:42będziemy mieć customers, możemy mieć Everything Customers, możemy

2:46mieć Order, Ring Customers itd.

2:48Te różne tabele mogą istnieć w bazie danych.

2:50Wiemy, który context odpowiada za którą tabele.

2:53I tutaj musimy bardzo duży nacisk położyć na to, żeby poszczególne konteksty

2:58pilnowały tego, że tylko dany kontekst owner danej tabeli może do niej zapisywać.

3:05Jest to prosta metoda na takie wizualne oddzielenie tabel między sobą.

3:10Jeśli już pracujemy z mikro serwisami, gdzie te bandit konteksty czy subdomeny

3:14będą osobnymi serwisami, będziemy mieć każdy mikro serwis z osobną

3:17bazą, co jest właściwie dobrą praktyką.

3:19Więc mamy tutaj maksymalną izolację, bo są różne serwisy.

3:22No i skalowalność, bo te serwisy będą się mogły.

3:25Skalować. Niezależnie od siebie.

3:28Jeśli już dzielimy w ten sposób tabele czy dzielimy bazy danych.

3:32Pogadajmy chwilę o technikach tworzenia tabel i wydzielania

3:34odpowiedzialności między nimi.

3:36Musimy pamiętać o zasadzie jednej odpowiedzialności, gdzie każda tabela

3:40powinna należeć do jednego kontekstu i być zarządzana przez jeden zespół lub inaczej

3:44zespół odpowiedzialny za ten konkretny kontekst.

3:47Więc jeden kontekst odpowiada za migrację, za scheme tabeli.

3:50Za zapisy. Za odczyty.

3:52Jeden kontekst pilnuje swojej tabeli.

3:54Musimy pilnować też konwencji nazewnictwa, gdzie używanie spójnych konwencji

3:59przedrostków, przyrostka w nazwach tabel będzie pomagało nam w utrzymaniu porządku

4:04i zrozumieniu zależności, a także tego, do kogo ta tabela należy.

4:10Jeśli będziemy mieć jasno oddzielone odpowiedzialności

4:14poszczególnych tabel, oddzielone odpowiedzialności kontekstów,

4:17konieczny będzie publiczny interfejs API dla dostępu do danych danych kontekstu,

4:22więc będziemy odpytywać nie tabele, nie także jakiś inny kontekst.

4:27Nawet w obrębie monolitu Modular Monolitu Monolitu modularny będzie czytał z

4:33różnych tabel, z różnych kontekstów.

4:34Nie będziemy musieli pytając z jednego kontekstu, odczytując drugi kontekst

4:39będziemy musieli odczytać jako publiczne IP, a nie bezpośrednio

4:43wysyłać zapytania do bazy danych.

4:45No i na koniec możemy posłużyć się także Event Source ringiem.

4:49Taki event Source Ring będzie pomagał w tym, że będzie

4:52jedno źródło prawdy w formie zapisanych eventów i będziemy te zmiany w systemie

4:58zapisywać jako serię eventów, przez co poszczególne konteksty mogą sobie

5:04nasłuchiwać na te zdarzenia i synchronizować swój stan między sobą na

5:09podstawie danych publikowanych w zdarzeniach domenowych.