0:00 / 0:00

Domain Driven Design: Odkrywanie bounded contextów

dla Architektów Oprogramowania

2 godz. 1 min · Full-stack i Programowanie

Rafał PiekaraSoftware Komandos

Czego się nauczysz

Poznasz pojęcie domeny i nauczysz się definiować jej cechy
Nauczysz się rozróżniać subdomeny od kontekstów ograniczonych
Projektowanie bazy danych dla Twojej domeny nie będzie już problemem
Nauczysz się definiować i testować wzorce taktyczne DDD
Zobaczysz zastosowanie DDD na praktycznych przykładach prawdziwych domen biznesowych
Przejdziesz proces implementacji DDD w kodzie legacy

Wzorce strategiczne DDD

Zanurzymy się w definiowanie strategicznych wzorców Domain Driven Design, które stanowią fundament efektywnego zrozumienia problemów biznesowych. Omówimy kluczowe koncepty takie jak Subdomena czy Bounded Context.

Wzorce taktyczne DDD

Wzorce taktyczne to praktyczne aspekty DDD, które są kluczowe dla każdego architekta oprogramowania. W tej sekcji mocniej spojrzymy na kod. Dowiesz się, jak stosować i testować wzorce takie jak Value Object, Encja czy Agregat.

Praca z bazą danych a DDD

Bazy danych to serce wielu systemów, a ich prawidłowe użycie w kontekście DDD jest kluczowe. Omówimy najlepsze praktyki związane z integracją domeny i kontekstów z tabelami bazodanowymi. Poznasz techniki, które pozwolą Ci zachować integralność danych i spójność modelu domenowego, niezależnie od wybranej technologii bazodanowej.

Praktyczna implementacja Domain Driven Design na przykładach

Teoria jest ważna, ale praktyka czyni mistrza. Przejdziemy przez konkretne przykłady implementacji DDD w rzeczywistych projektach. Zobaczysz krok po kroku zastosowanie wzorców, zamodelowanie domeny i implementację. Praktyczne przykłady pomogą Ci zrozumieć, jak stosować DDD w codziennej pracy i jak wpływa to na komunikację z interesariuszami biznesowymi.

Refactoring Big Ball of Mud

Każdy architekt oprogramowania spotkał się z systemami, które były nieczytelne i trudne do utrzymania - tak zwanymi "Big Ball of Mud". Nauczysz się, jak za pomocą DDD przeprowadzić refaktoryzację takiego systemu, przekształcając go w dobrze zorganizowane i zarządzalne struktury.

Dla kogo jest ten kurs?

Kurs powstał z myślą o programistach aspirujących do roli architektów, architektach oprogramowania oraz liderach technicznych, którzy chcą pogłębić swoją wiedzę i umiejętności w zakresie stosowania Domain Driven Design. To materiał idealny dla tych, którzy znają już podstawy DDD i chcą podnieść swoje umiejętności na wyższy poziom, aby projektować złożone i skalowalne systemy. Niezależnie od tego, czy pracujesz nad dużymi projektami, chcesz usprawnić komunikację z zespołem i interesariuszami, czy szukasz nowych strategii na rozwiązywanie skomplikowanych problemów biznesowych - ten kurs jest dla Ciebie!

0:00No i przyszła pora na KOR.

0:01Odkrywanie bandy kontekstów KOR domain Driven Design.

0:05O ile zagadnienia domeny i subdomeny są trochę bardziej abstrakcyjne,

0:11bardziej ogólne i dotyczą definicji problemów biznesowych,

0:16to Bandit konteksty to już czysta implementacja.

0:19Czyli tutaj tak naprawdę na grubo wjeżdżają programiści.

0:24Podstawą wydzielenia bandery kontekstów odkrycia tych naszych granic

0:29między kontekstami, między modułami systemu jest zrozumienie domeny poprzez

0:34analizę samej domeny, jej subdomen, co już omawialiśmy wcześniej.

0:38Komunikacja z biznesem wjeżdża cały czas.

0:41To jest bardzo ważny punkt całego zagadnienia Domain driven Design.

0:45Żeby być w bieżącej komunikacji z interesariuszami ekspertami domenowych.

0:52Analizujemy modele domenowe pod kątem granic, więc mamy już ten model

0:57zdefiniowany na etapie definiowania domeny subdomen.

1:00I teraz szukamy granic.

1:01Szukamy miejsc, w których te konteksty bardzo mocno się odcinają.

1:06Będzie osobna lekcja o szukaniu granic, więc nie wchodzimy tutaj zbytnio w

1:11szczegóły, jeśli chodzi o takie szukanie granic.

1:15Polega to na identyfikacji naturalnych granic w problemach biznesowych, więc tak

1:19ogólnie tylko sobie teraz omówimy i identyfikując te granice obserwujemy

1:25punkty zmiany języka domenowe.

1:28Dobrym przykładem jest ecommerce, gdzie produkt magazynowy to nie jest ten sam

1:32produkt, który jest w pressingu w offer ringu, bo w pracy ringu możemy mieć np.

1:37paczkę książek.

1:38Natomiast magazynie produkt to jest fizycznie jedna książka.

1:43Kontekst musi być spójny, musi być spójny z modelem, musi być spójny w obrębie

1:48modelu, nie może być z nim sprzeczny.

1:51Nie może procesować operacji totalnie niezwiązanych z modelem biznesowym.

1:56Klasycznym obrazem kontekstów jest modularny dość, więc konteksty funkcjonują

2:00w modułach, są niezależne od siebie i naszym zadaniem jako programistów jako

2:05architektów jest zapewnienie niezależności tych kontekstów poprzez wydzielenie

2:09odpowiednich granic i zaplanowanie interakcji między nimi

2:12w odpowiedni sposób.

2:14Te konteksty nie mogą się jakoś przenikać.

2:16One muszą mieć ze sobą ściśle określone interakcje, ściśle określony kontrakt.

2:22No i wszystko ewoluuje, więc tutaj ewoluuje.

2:26Czy nasze konteksty faktycznie mają jasno wydzielone granice, konkretnie

2:30wydzielone i dostosowujemy te granice w czasie, Jesteśmy otwarci na te zmiany.

2:35No i jeśli chodzi o samo szukanie granic, musimy popatrzeć tak na procesy biznesowe,

2:41gdzie granice często pokrywają się z różnymi procesami biznesowymi, więc

2:45mamy jasno wydzielone te granice.

2:46Przykładem jest, jak już mówiłem, everything i marketing.

2:49Bardzo jasno widać zakres granic, nie fakturowanie czy działalność

2:55marketingowa firmy.

2:56Szukamy języka, gdzie język zmienia się między kontekstami, między granicami.

3:03Mówiłem o tym produkcie, że produkt w pracy będzie czymś

3:07innym niż produkt w magazynie.

3:09Język się zmienia, pojęcie jest to samo, ale już język, rozumienie

3:12tego pojęcia się zmieniło.

3:14I to jest ten moment, gdzie możemy wytyczyć granicę.

3:18Patrzymy na zależności, gdzie mniejsza liczba zależności

3:21sugeruje nam naturalną granicę.

3:23Im mniej zależny jest kontekst, im bardziej niezależny, niepodległy kontekst.

3:29Można powiedzieć independent.

3:31Po angielsku mówią architekci.

3:33To ten kontekst ma większą szansę, żeby być tutaj samodzielnym kontekstem.

3:39Musimy bardziej się zagłębiać.

3:42Patrzymy też na to, co się zmienia w obszarze kontekstu.

3:46Obszary częstych zmian mogą wymagać oddzielnego kontekstu.

3:50Jeśli coś często się zmienia razem, spójnie, czyli dane, które

3:54zmieniają się razem, jakieś klasy, które zmieniają się razem,

3:57to jest dla nas wskazówka, że może powinniśmy właśnie ten zakres

4:01wydzielić do oddzielnego kontekstu.

4:04Punkty integracji z zewnętrznymi systemami także mogą nam sugerować granice, więc

4:10często będzie tak, że integracja z systemem.

4:13Adaptery, które będziemy wpinać do naszego systemu pluginy mogą sugerować,

4:18gdzie granica kontekstu przebiega.

4:21Każda integracja może mieć osobny kontekst, może mieć, więc

4:26warto na to zwrócić też uwagę.

4:29Mówiłem już o zmienności danych, więc będzie tutaj trzeba poruszyć temat bazy

4:34danych, więc w następnej lekcji pokażę jak pracować z bazami danych i

4:38kontekstami ograniczonymi.

4:40A więc to, jakie bundle Context ma wpływ na strukturę i nazewnictwo w bazie danych.