0:00 / 0:00

Domain Driven Design: Definiowanie encji

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:00Kolejny z wzorców tych praktycznych wzorców, wzorców taktycznych.

0:04Domain Driven Design to encja.

0:06Co to takiego jest encja?

0:08Encja jest obiekt, który będzie już miał jakiś stan.

0:12Identyfikacją tego obiektu będzie jego unikalny identyfikator, więc jeśli możemy

0:16wskazać jakąś prostą różnicę między value obiektem a encji, to będzie to

0:21właśnie unikalny identyfikator.

0:23Więc te same encje z tymi samymi wartościami, ale z różnymi

0:27identyfikatorami będą się różniły.

0:31Encja ma jakiś dłuższy cykl życia i może zmieniać stan, więc na encji

0:35mogą zachodzić pewne operacje.

0:38Encja Entity charakteryzuje się pewną trwałością i tak jak już mówiłem równość

0:43opiera się na unikalnym identyfikatorze, a nie na atrybutach.

0:47I jakie są elementy encji?

0:49W pierwszej kolejności mamy zawsze ten unikalny klucz identyfikator i to jest

0:54coś, co jest wymagane przy tworzeniu i definiowaniu encji.

0:58Mamy atrybuty, więc encja ma jakieś pola, charakterystyczne cechy i może mieć

1:02metody, czyli operacje i zachowania, które zmienią jej stan.

1:06Jak to będzie wyglądało w kodzie?

1:08Zobaczmy na przykładzie prostej encji user.

1:11Mamy tutaj zdefiniowaną klasę usera, które ma pole read only ID.

1:16Więc ono jest niemal totalne ID.

1:18Identyfikator się nie mutuje i jest on przyjmowany w konstruktorze, więc w

1:22konstruktorze przyjmujemy też name i email.

1:25No i encja ma tak.

1:27To co zwaliło projektu tutaj zauważymy ma zaimplementowaną metodę equals i ta metoda

1:31equals porównuje tylko ID, porównuje ID, nie porównuje w ogóle atrybutów.

1:38Mamy też zmianę stanu w postaci funkcji

1:41update email, gdzie możemy zmienić email naszego użytkownika i tworząc dwóch

1:46różnych użytkowników z tym samym imieniem z tym samym

1:49mailem, ale z różnymi identyfikatorami.

1:52Otrzymamy tutaj nierówność.

1:55Te dwie encje nie będą równe, bo różnią się identyfikatorem, ale

2:00encja sama w sobie ma jakieś zachowanie, jakiś cykl życia.

2:03Jest możliwa zmiana maila w naszej encji?

2:06Bardzo prosta definicja, ale widać tutaj charakterystyczną różnicę, gdzie

2:10identyfikator jest głównym atrybutem, który wyróżnia encje

2:15spośród innych obiektów.