dla Architektów Oprogramowania
2 godz. 1 min · Full-stack i Programowanie
Rafał PiekaraSoftware KomandosZanurzymy 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 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.
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.
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.
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.
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!
Zapraszam Cię teraz do modułu poświęconego faktoringu.
Przygotowałem dla Ciebie mega ciekawe przykłady z domeny systemu
do publikowania ogłoszeń na OLX i ten kod.
Co tu dużo mówić to jest tzw.
Big Ball of Mart, czyli taki mega gruby serwis, który robi dużo rzeczy.
I spróbujemy go teraz zrestrukturyzować w kierunku Domain Driven Design i pierwszym
krokiem będzie właśnie wydzielenie value obiektów i encji z tego wielkiego
monolityczny serwisu, Więc poszukajmy co tu się dzieje.
Najpierw sprawdźmy strukturę.
Można tutaj dodać jakiegoś użytkownika, więc pewnie to jest
po prostu rejestracja użytkowników w systemie, podstawianie ogłoszenia.
Tutaj się coś dzieje właśnie z tymi ogłoszeniami.
Można wyświetlić liczbę ogłoszeń, można znaleźć ogłoszenie za pomocą kategorii,
czyli po prostu filtrowanie po kategoriach.
Można zalogować użytkownika, można usunąć ogłoszenie, można dodać kategorię.
Jak widzisz, dużo się dzieje w jednym systemie.
Na pewno gwałcone są wszystkie zasady SOLID, bo zasady pojedynczej
odpowiedzialności na pewno tutaj nie ma.
Ale żeby z czymś tutaj zacząć, najprościej będzie wydzielić sobie value objects.
I to jest taka dobra technika, jeśli mamy do czynienia z takim wielkim kodem legacy
i chcemy wejść trochę bardziej w projektowanie domenowe,
poszukajmy sobie value object.
To mi się już tutaj pokazuje email, który mógłby być świetnym value obiektem,
który będzie należał do użytkownika.
Więc stwórzmy nowy katalog, nazwę jego value object.
I tworzymy tutaj nową klasę maila.
I to będzie email.
I będzie on wyglądał bardzo prosto.
Tutaj pilot mi podpowiada walidację, tu toString jeszcze za.
Implementujemy metodę equals, żeby zadość uczynić wszelkim wzorcom
związanym z tworzeniem value object.
Więc mamy email, szukamy dalej.
Szukamy dalej. Co to mogłoby być?
Może być password, więc stwórzmy sobie password, bo użytkownik ma jakieś hasło.
Więc nasze hasło też może być value obiektem i będzie miał jakąś
wartość i tą wartość można pobierać.
OK, może mieć też equals.
Przyda nam się porównywanie haseł, więc mamy hasło, mamy emaila,
poszukajmy dalej co tu może być.
A tutaj widzę np.
Price, więc możemy dodać ogłoszenie, które ma jakąś cenę, bo np.
sprzedaż mieszkania, mieszkanie ma jakąś cenę, więc dodajmy value object price.
I tutaj nasz price ma wartość Ma, dodajemy tutaj zamiast value zmienimy na amount
i zrobimy currency.
To zrobimy amount.
I dodajmy currency.
Będzie to get value jest niepotrzebne, wystarczy sama metoda equals.
Która będzie porównywać ceny.
Więc mamy value object ceny, Mamy Price.
Poszukajmy jeszcze czegoś.
Jak widzimy tu mamy ogłoszenie, więc mogłoby być tak, że np.
i description i title są jakimiś typami, więc możemy utworzyć takie value objects.
Title może być tutaj po prostu obiektem wartości i on może
zawierać też w sobie jakieś dodatkowe metadane.
Ale utwórzmy sobie title i niech on ma tutaj value string
i niech ma jakąś walidację.
No i utwórzmy sobie też description jako ćwiczenie tworzenia value obiektów.
I taki description mamy walidacja dla description i wrzucanie wyjątku,
więc mamy tutaj walidację tego naszego value obiektu.
Wydaje mi się, że zaadresować takie podstawowe obiekty wartości.
Możemy teraz poszukać encji i skoro mieliśmy użytkownika.
To już widzę, że tą podstawową esencją może być właśnie użytkownik.
Więc zróbmy sobie tutaj folder NTFS i dodajmy sobie usera.
I zobaczmy co ten użytkownik mógłby tu mieć.
Na pewno będzie miał.
Na pewno będzie miał imię i nazwisko.
To może niekoniecznie.
Na pewno ma email a.
Hasło OK, e-mail.
Ma e-maila i ma jeszcze jakieś pole is admin, więc może być administratorem,
więc dodajmy tutaj.
Is admin.
Tak samo do konstruktora niech się tutaj tworzy is admin.
No i jeśli to jest encja to musimy mieć co musimy mieć.
Read only ID.
Konto ma też identyfikator.
Mamy encje użytkownika.
W ten oto sposób Ja sobie mam wyeksportować, bo
możemy tego użyć w naszym serwisie.
Za chwilę mamy tu użytkownika.
I spróbujmy zastosować naszego użytkownika.
W takim razie jest users będzie tablicą użytkowników.
OK w tym naszym systemie mamy user, to jest user links.
I jeśli tu będziemy mieć użytkownika, który ma pole email więc możemy sobie
teraz porównać mamy tego usera
zamiast email takiego stringa dodamy mu naszego emaila z value obiektów
to eksportujemy tę klasę email.
OK.
Importujemy.
Poprawimy jeszcze typowanie.
Jesteśmy w trakcie faktoringu, więc tutaj możemy dokonać porównania, bo nasz email
implementuje metodę equals, więc nie musimy robić tego w ten sposób, tylko
możemy zrobić email i email i już jest coś lepiej.
Zaczynamy implementować nasz kod domenowe w tym systemie.
Username ok.
To nic więcej nowego nie dzieje.
Add user.
Tutaj dodajemy coś, co nie jest obiektem, więc możemy utworzyć tutaj
nowego użytkownika, np.
New User i to będzie nowy użytkownik.
Nowy użytkownik.
Coś zepsuł z adminem.
I z adminem było dobrze.
Mamy nowego użytkownika, jest ok.
I tutaj zamiast takiego.
Możemy dodać sobie tylko naszego nowego usera.
No i coś się już zaczyna dziać fajnie w tym systemie.
Ja widzę jeszcze tutaj kategorii taką encja mogłaby być kategoria,
więc utworzymy sobie category.
I ona będzie miała jakiś tam name i to jest spoko i dodamy sobie oczywiście.
ID.
No i mamy hit! Mamy category i mamy usera.
Tak samo tutaj możemy zrobić categories.
Mamy jakieś podstawowe kategorie, więc nic nie stoi na przeszkodzie,
że stworzymy sobie tutaj nową tablicę
kategorii już za pomocą naszych encji.
Dajmy ID.
Oczywiście w realnym projekcie te kategorie mogłyby być wyciągane z bazy
danych lub numery ID mogły być generowane np.
za pomocą UID.
Ale to widzę. Osiągnęliśmy zamierzony cel.
Jest całkiem nieźle.
Mamy kategorię.
Jeśli kategoria równa się kategorię, więc możemy zaimplementować metodę equals w
kategorii, która będzie z kolei porównywać nam ID.
I tu możemy sobie zrobić.
Equals kategorię w porównywaniu.
Całkiem nieźle zaczyna to wyglądać, więc podzieliliśmy sobie podstawowe,
bardzo podstawowe encje i value object.
Ty możesz iść dalej tym faktoringu, natomiast my już mamy pewien zarys.
Coś się tutaj zaczęło dziać.
W następnej lekcji, w następnym faktoringu, w następnej części zajmiemy
się dalszą przemianą tego naszego wielkiego, potężnego serwisu AdWords Smart
System i będziemy szukać serwisów i agregatów.
I ja myślę, że takim agregatem jak mamy odwierty expand.
Naszym kluczowym obiektem może być obiekt samej reklamy.
Zobaczymy jak to będzie wyglądało.
Zapraszam Cię już teraz do kolejnego materiału.