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!
Przejdźmy teraz do przykładów wykorzystania Domain Driven Design
w realnych problemach biznesowych.
Pierwszym przykładem będzie model biblioteki, więc będziemy
tu mieć Dome nowy model biblioteki.
Zapraszam Cię teraz do kodu.
Przejdziemy sobie przez te katalogi, które tutaj mamy.
Po tworzone mamy katalog Agregaty Application Services Domain Services
Entity jest Person Instance i Value objects.
Zaczniemy od Value Objects.
Mamy zdefiniowany jeden value Object, którym jest ISBN.
I tutaj rzucamy wyjątek odnośnie walidacji formatu ISBN u.
Nie ma tutaj metody equals, bo nie będziemy potrzebować
tutaj porównywać tych ISBN ów.
Przejdźmy teraz do Entity.
Jakie mamy tutaj encje zdefiniowane?
Pierwszą opcją jest książka, która będzie miała numer ISBN.
I ten.
Numer ISBN będzie dla nas unikalnym identyfikatorem tej encji.
Mamy też tytuł autora oraz stan czy książka jest dostępna czy nie i możemy
sobie zrobić, że ta książka jest już niedostępna oraz że ona będzie dostępna.
I to jest pole publiczne do odczytu tej encji książki Book.
Będziemy mieć jakiegoś czytelnika, który ma unikatowy identyfikator
ID oraz nazwę prosta encja.
No i co tu będziemy mieć dalej?
Będziemy mieć agregat.
Ten nasz agregat to jest wypożyczenie.
Wypożyczenie książki.
Ten agregat będzie przyjmował ID, będzie przyjmował książkę czytelnika,
datę wypożyczenia i datę zwrotu książki.
Co tu możemy zrobić?
Mamy inicjalizacja tego agregatu.
Oznaczamy książkę jako niedostępną, bo tworzymy nowe wypożyczenie i możemy
wykonać operację biznesową, która polega na zwrocie książki.
Zwrot książki polega na tym, że określamy książkę jako dostępną z powrotem
i ustalamy datę zwrotu na datę aktualną. I to są.
To jest agregat.
Mamy tutaj pewną regułę biznesową dotyczącą dostępności książki, ale mamy
też aplikacyjne serwisy i domenowe serwisy.
Więcej na ten temat dowiesz się w lekcjach i w materiałach
wprowadzających do Domain Driven Design dostępnych w serwisie E Web.
Zobaczmy, co tutaj znajdziemy.
Mamy jakiś serwis biblioteczny?
To jest główny serwis zarządzania naszą biblioteką, czyli taki entry point i to
będzie wywołane przez jakieś zewnętrzne API, np.
Controller w frameworku webowym i on tutaj przejmuje repozytoria.
O repozytoriach za chwilę, ale ma operację log book.
I co tu się dzieje?
Pobieramy sobie jakąś książkę z repozytorium, pobieramy sobie
czytelnika z repozytorium i pobieramy.
Budujemy sobie tutaj agregat i tworzymy sobie tutaj nową
instancję serwisu Loan Service.
Wykonujemy operacje Lombok.
To jest service domenowe i zaraz przejdziemy.
No i na końcu zapisujemy sobie to wypożyczenie czyli stan naszego agregatu.
I co robi nam Loans Service?
Po co jest w ogóle ten launch service?
A na dole serwisu deleguje sobie logikę, która mogłaby być zbyt złożona
tutaj dla naszego serwisu aplikacyjnego.
Więc tu jest logika biznesowa, więc wrzucamy jakiś wyjątek.
Jeśli książka jest niedostępna i tworzymy nową instancję agregatu wypożyczenia.
I tutaj możemy oddać książkę.
Lubią wypożyczyć.
No i przejdźmy jeszcze do repozytoriów.
Ja tutaj utworzyłem dwa bardzo proste interfejsy repozytoriów.
Pierwszy to jest Book Repository, drugi to jest Loan Repository.
Są to interfejsy, których możemy zaimplementować do odczytu poszczególnych
elementów i zbudowania encji agregatów, więc możemy sobie znaleźć
książkę po USB i lub ją zapisać.
Tak samo możemy sobie nasz agregat wypożyczenia zapisać w bazie danych z
serializacji i tak by wyglądała bardzo przykładowa aplikacja
biblioteczna za modelowania.
Podstawowa operacja wypożyczenia książki Jak widzisz ten model jest przejrzysty.
Już po samym drzewie plików można się dowiedzieć co się tutaj w
systemie dzieje, a już wejdziemy w lekcje.
Wszystko jest czytelne i właśnie dzięki temu Domain Tree Design jest skuteczne w
budowaniu aplikacji, bo mamy tę logikę domen, ową logikę biznesową
bardzo wyraźnie zapisaną.
I nawet dam sobie rękę uciąć, że dla osoby nie technicznej ten kod mógłby być
w pewnym stopniu bardzo zrozumiały.