Domain Driven Design: Refactoring II - Wydzielanie serwisów
dla Architektów Oprogramowania
2 godz. 1 min · Full-stack i Programowanie
Rafał PiekaraSoftware KomandosCzego 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!
Ale faktoringu ciąg dalszy.
Teraz popracujemy nad wydzieleniem serwisów i agregatów z naszego systemu.
Jeśli chodzi o serwisy to będzie dość proste, bo po prostu oprzemy się na tych
metodach, które tutaj mamy, więc mamy jakieś.
Coś będzie dotykającego użytkownika, do tego przejdziemy za chwilę, ale mamy tutaj
po prostu podstawianie reklam i wyszukiwanie tych ogłoszeń i też
wyszukiwanie po kategorii, więc przejdziemy do serwisów aplikacyjnych.
I tutaj znajdziemy.
Stworzymy sobie może taki ad service.
I tak będziemy mieć Add Service i stworzymy sobie tutaj kilka metod.
Na pewno post Ad.
Spróbujemy odwzorować to, co mamy.
List Ads.
Niech to będzie tak jak jest I find box category.
OK, zajmijmy się tym Find by category.
To jest dość proste.
Tu sobie przekażemy category.
więc mamy tutaj encje, którą będziemy przekazywać.
Tu mamy ładny typ i w zasadzie możemy sobie w dużej mierze przenieść.
Tutaj.
Sprawdźmy, czy w kategorie mamy metodę equals.
Mamy, więc możemy zrezygnować z tego porównania i po prostu skorzystać.
Z metody equals.
Mamy i tu mamy found ads.
OK i mamy this ads, więc możemy.
Mamy Find Ads plik Category, więc możemy tutaj zamiast This ads zrobić po
prostu const ads i to będzie this.
list ADC.
Czyli pobieramy metodę inną metodą tego serwisu.
Lecimy tak po prostu.
Tu będziemy upraszczać te pętle.
Nie będę wnikał w szczegóły języka JavaScript czy skryptu.
OK, czyli mamy find by categories.
Zwracamy jakąś tablicę, Dodajmy sobie tutaj ad tablicę reklam
i od razu się pojawiło coś nowego. Nowy.
Nowa encja, encja lub też może agregat.
Więc dodajmy tutaj nowy katalog Domain i tutaj sobie utworzymy add
i potraktujmy ten nasz add jako agregat. Expert Add.
Export class.
Mamy tutaj klasę wyeksportowane i możemy sobie tutaj zaimportować.
No i dużo lepiej to będzie teraz wyglądało.
OK, więc mamy tę metodę Find page Category list Add to będzie jakieś
pobranie reklam, więc zróbmy tu.
Może po prostu zwróćmy jakąś tablicę?
Kilku ogłoszeń?
Potraktujmy to jako takie repozytorium w pamięci, więc mamy fajne kategorie
i zostaje nam to możemy usunąć.
W takim razie możemy też usunąć.
Post add i zostaje nam. co zostaje.
Post A więc mam jakiś user name, title, description, category i price.
Możemy sobie to uprościć.
Zamiast user name.
Dodamy usera.
Title Mamy już utworzony typ title Value Object, więc możemy go wyeksportować i też
z niego korzystać, więc korzystamy z tych wielu obiektów, które już mamy stworzone,
czyli title, description i price.
OK, więc możemy mieć tutaj title.
Możemy mieć description.
Który ma typ description i możemy mieć.
kategorie typu category i price, który też będzie miał.
Typ price OK, więc możemy sobie zaprojektować taką reklamę.
Zakładamy, że nie potrzebujemy już ani User found, ani category
found, bo to już mamy ściągnięte.
Kopiujemy ciało tej metody post, add at i spróbujemy je trochę pozmieniać.
Oczywiście gdybyśmy mieli tutaj testy to by było o wiele prostsze.
Natomiast to ćwiczenie ma za zadanie przećwiczenie się w modelowaniu
Domain driven Design.
Nie potrzebujemy już tutaj mapować tych kategorii, bo mamy kategorię,
którą potrzebujemy.
Nie potrzebujemy tego, bo kategoria już jest znaleziona.
Tak samo nie potrzebujemy tutaj użytkowników walidacji dla użytkownika,
natomiast będziemy tworzyć nową. Nowe ogłoszenie.
Add new Add title, Description size user i automatycznie się pokaże, jakie pola
tutaj będziemy potrzebować.
OK, dodajmy tutaj typowanie, żeby było wiadomo.
Jakie pola będą potrzebne.
Więc mamy category będziemy mieć Price.
I ten nasz ads stanie się teraz agregatem, bo on już zaczyna mieć bardzo dużo
różnych rzeczy, obsługiwać bardzo dużo różnych rzeczy.
Tutaj zjadłem sobie nawias i tutaj importujemy jeszcze usera.
Całkiem dobrze to zaczyna wyglądać.
Przejdźmy z powrotem.
Tu więc mamy add, więc to nam nie będzie potrzebne, to nam nie będzie potrzebne to
też to i to i nasz post add będzie miał tworzenie nowej reklamy
i sobie zrobimy tutaj.
Post.
I dodamy status.
W takim razie read only status.
Który będzie miał np.
formę draft jako default owy, natomiast stworzymy typ dla statusu,
więc może mieć draft albo post.
Więc mamy ogłoszenie w drafcie, mamy ogłoszenie, posted i tu zmienimy status.
To się równa Posted Disc Status, Draft Wszystko gra,
Zatem to read only to zrobimy, read only zrobimy Nie, Zostawmy
status jako publiczne.
Więc mamy post i tutaj w tym naszym postac możemy zrobić po prostu ad post.
Elegancko Tutaj tylko poprawimy za pomocą GitHub.
Pilot tworzenie reklam, tworzenie ogłoszeń.
Więc robimy sobie new ad tworzymy.
New Title i tworzymy nową.
Nowe ogłoszenie.
Kolejne i kolejne, żebyśmy mieli jakieś ogłoszenia w naszej bazie.
No i mamy.
Możemy sobie zaprojektować nową reklamę, nowe ogłoszenie, np.
sprzedać jakieś mieszkanie.
Możemy wylicytować i pobrać.
Wszystkie ogłoszenia z bazy możemy wyszukać za pomocą kategorii.
No i została nam tu jeszcze operacja.
usuwania, więc dodamy operację usuwania.
Powiat ID i nasz Add serwis.
Dorzucimy referencje do Add Repository.
I takie repozytoria utworzymy.
Tutaj w katalogu Existence robimy Add Repository.
OK, będzie miał save.
I zróbmy sobie jeszcze delete elegancko.
Może niech nie wraca Wojda, tylko niech po prostu nie zwraca Promise,
ale będzie Void i.
Niech się nic nie dzieje.
I tak samo tutaj.
Nie, my potrzebujemy tego.
Potrzebujemy po prostu takie zwykłe zaślepki.
Więc to gra i będziemy mieć add post i zrobimy add repository save i tak
samo tutaj będziemy mieć ad repository.
Delete ad id.
I to wszystko.
Więc to możemy już tutaj wyrzucić.
Delete add i nasz serwis ten advertising and service zrobił się trochę chudszy.
W dalszej części wydzielić możemy sobie np.
tutaj Ad category No i te wszystkie operacje związane z
użytkownikiem, więc przejdźmy teraz do tego.
To co mi się tutaj nie podoba to mamy to.
Ad category Właśnie.
I to powinno być jakiś taki po prostu Application Service, który będzie
polegał na dodawaniu kategorii.
Category Service serwisant będzie miał znaczenie.
Get categories robimy.
Add category.
No i on niech sobie tu tworzy nowe kategorie przez Category Repository,
które możemy utworzyć i to nam odpadnie.
Nie potrzebujemy już tutaj kategorii.
I teraz mamy operacje związane z użytkownikiem.
I o co chodzi z tymi operacjami związanymi z użytkownikiem?
One na pierwszy rzut oka wyglądają na to, że nie należą do naszej
domeny, do naszej domeny.
Asortyment to jest raczej kontekst identyfikacji, kontekst
autoryzacji, więc utwórzmy tutaj.
Nowy katalog, który następnie nazwiemy Advertising MC.
Moments i do tego katalogu przeniesiemy ten cały
nasz kod, który do tej pory z refaktoryzacji
daliśmy i stworzymy nowy katalog Identity.
Często tak się określa kontekst dotyczący autoryzacji
użytkowników, więc mamy Identity i możemy tutaj mieć application.
To będzie katalog.
I tu będziemy mieć out service np.
out service i w tym naszym out service powinniśmy zawrzeć.
Te operacje, czyli będziemy mieć tutaj login, login i wystarczy login i jeszcze
może być ten Create register user, prawda?
Więc możemy mieć to Zlikwidujemy te wszystkie operacje, które tu zobaczyliśmy,
które nam pilot podpowiedział.
Celowo właśnie tutaj posługuję się pilotem i ten faktoring jest taki
na żywca, można powiedzieć, żeby pokazać cały ten proces,
który tutaj przebiega, jeśli chodzi o tworzenie i rysowanie kodu do Domain
Driven Design, więc tutaj do Register.
Zrobimy sobie to.
I dodajmy sobie jakieś User Repository.
Które może być wygenerowane.
I zróbmy tak, że mamy Register user.
New user OK.
Utwórzmy tylko nowego użytkownika poprawnie.
Jakieś ID User name Password.
Niech on ma nowy email.
Jeszcze niech tu przyjmie.
OK.
Dobrze to wygląda i zrobimy user repository i save user.
OK, to mamy register.
OK.
I tu mogą być operacje do logowania użytkownika do wylogowania
użytkownika, więc to już zostawię.
Logowanie.
Wylogowanie.
I możemy już sobie stąd wyrzucić.
No i trochę ten nasz asortyment service advertising System się zmniejszył.
W następnej lekcji posłużymy się zdarzeniami nowymi.
No i spróbujemy jakoś ten float z tego systemu odtworzyć już z wykorzystaniem
naszych domenowych obiektów.
Identity Advertising Tutaj jeszcze przed końcem warto by przenieść password
do kontekstu identity, więc spójrzmy jeszcze Value Objects
i do niego przeniesiemy password.
email.
I encje użytkownika.
OK, dobra, dużo się zmieniło.
Mamy aktywowany system, wiedzieliśmy reklamę mamy AD Service Category Service,
mamy encje Category, mamy repozytorium, mamy value obiekty.
Mamy też osobny context, który służy do autoryzacji autentykacji użytkownika.
W następnej lekcji wdrożymy zdarzenia domenowe, czyli zdefiniujemy za pomocą
zdarzeń domenowych, co wydarzyło się w naszym systemie, tak aby móc umożliwić np.
innym tekstom nasłuchiwanie na te zdarzenia.
Więc zapraszam Cię do kolejnego, ostatniego już materiału z dziedziny
faktoringu w Domain Driven Design.
W tym kursie.