0:00 / 0:00

Domain Driven Design: Granice kontekstó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:00Na koniec, w kontekście jeszcze tych teoretycznych podstaw dotyczących

0:04budowania architektury oprogramowania w Domain Driven Design

0:08porozmawiajmy o granicach kontekstów.

0:10Definiowanie granic kontekstów jest jedną z podstawowych technik umiejętności,

0:17które pozwalają nam efektywnie pracować z domeną i z jej granicami.

0:22W pierwszej kolejności musimy dokonać przeglądu języka.

0:26Konieczne jest tutaj sprawdzenie, aby język był spójny wewnątrz kontekstu i

0:32zdefiniować te cechy, którymi ten język będzie się różnił pomiędzy kontekstami.

0:37Więc szukamy wspólnych pojęć.

0:39Szukamy wspólnego rozumienia zagadnień, Szukamy wspólnego zrozumienia domeny,

0:46kontekstów i całej logiki biznesowej, która w skład wchodzi, tak, aby ta część

0:52biznesowa zespołu, część inżynierska i programistyczna rozumiała się

0:57mówiąc tym samym językiem.

1:00Analiza zależności pomoże zminimalizować zależności czy zminimalizować

1:06przepływ danych między kontekstami.

1:08Większe zależności jeśli jeden kontekst bardziej zależy od drugiego,

1:12mogą wskazywać na to, że granice są źle wyznaczone.

1:15Jeśli mamy jakiś odczyt danych w trakcie jednej operacji w danym kontekście,

1:21który konieczny jest do wykonania z innych kontekstów, będzie to dla nas taki znak,

1:25że coś tutaj zostało źle wyznaczone.

1:29Konieczne jest też zbieranie feedbacku od zespołów, opinii od developerów i biznesu,

1:34tak aby wyłapywać wszelkie niejasności w rozumieniu pojęć w rozumieniu języka

1:39i niejasności w projekcie.

1:40W samym modelu domenowych, które mogą wskazywać na te właśnie niejasne granice.

1:45A to z kolei doprowadza nas do oceny modelu biznesowego,

1:48aby upewnić się, że granice wspierają cele biznesowe i procesy.

1:52Jeśli granice tylko utrudniają realizowanie rozwoju systemu,

1:56oznacza to, że coś trzeba przerobić, jeśli chodzi o sam model kontekstów.

2:02No i wreszcie tak jak domena się zmienia, system się zmienia, konieczne są iteracje,

2:06regularny przegląd i dostosowywanie granic w miarę ewolucji projektu i organizacji,

2:11więc będziemy mieć do czynienia z przenoszeniem klas, ze zmianą interfejsów,

2:15może ze zmianą nawet struktur danych, czy przenoszenie jednych tabel

2:18do drugiego kontekstu.

2:20To wszystko będzie żyło w miarę jak nasz system będzie się rozwijał.