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!
Kolejny bardzo ciekawy przykład to przykład domeny warsztatu samochodowego.
Zobacz jak wygląda za moderowana domena warsztatu samochodowego z
wykorzystaniem tych wszystkich wzorców, które do tej pory poznałeś.
Value Objects zaczynamy od Value Objects od najprostszych wartości numer VIN,
numer unikalny identyfikator samochodu.
Value Object VIN.
Przechodzimy do repozytoriów.
Mamy tutaj dwa repozytoria do pozyskiwania ripper job ów.
Jak zapewne widzisz, Ripper job, czyli usługa wykonania naprawy samochodu.
To jest nasz agregat, więc będziemy mieć tutaj repozytorium,
które nam zwróci obiekt agregatu i klienta W agencjach będzie to samochód, który ma
unikalny identyfikator i ten unikalny identyfikator jest z kolei wartością,
wartością value Object i numerem VIN. Ciekawy pattern.
Ciekawa technika zastosowana tutaj, że unikalny identyfikator
jest typem value obiektu.
No i mamy Customers, który z kolei będzie mógł mieć jakiś samochód, jakiś stan, ileś
samochodów zdefiniowanych na tym poziomie.
No i przejdźmy teraz do agregatu.
Agregat Ripper Job.
Jest trochę bardziej złożony niż do tej pory widzieliśmy,
więc taki agregat naprawy pojazdu będzie miał
pole Vehicle customers klienta, jakiś jego samochód, opis tej naprawy, no i ma też
różne statusy, więc będziemy tutaj zmieniać statusy tych metod dotyczących
zmian statusu jak komplet Repair Start Repair może być o wiele więcej.
Możemy mieć też open lub wiele innych.
Domyślnym stanem będzie dla nas stan otwartego agregatu, więc ten agregat jest
dość prosty, przyjmuje jakieś proste pola, proste typy, ma spójny stan.
No i będziemy tutaj zmieniać reguły biznesowe.
Moglibyśmy tutaj dodać np.
w TPP, że jeśli status.
Równa się completed.
To wtedy return.
Bo już ten status jest zakończony, już to zamówienie zostało już
then praca została zakończona lub też możemy tutaj rzucić wyjątkiem nowego.
Nowym wyjątkiem, który nam powie, że ta praca została już wykonana.
Przejdźmy teraz do serwisów Application Service.
więc tutaj mamy znowu referencję do repozytoriów i interakcję z nimi,
by wyciągnąć encje i agregaty. I sprawdzamy.
Jeśli mamy klienta, znajdujemy sobie jakiś pojazd tego
klienta, który chcemy tutaj naprawiać.
Jeśli nie ma tego pojazdu, to rzucamy wyjątkiem, że klient tego pojazdu nie ma.
Jest jakiś problem jeśli nie deleguje wykonanie tej logiki do repair
serwisu przekazujemy tam.
nasze encje, opis i Ripper Service zwróci nam już gotowy
agregat, który zapiszemy sobie do repozytorium.
I ten Ripper service jest bardzo prosty, bo on nam zbuduje nowy agregat i tutaj
na tym agregacie jest ripper serwisu.
Możemy wykonywać jakieś operacje więc nie stoi to nic na przeszkodzie.
Gdybyśmy tutaj chcieli od razu zakończyć naszą naprawę na tym poziomie,
wykonać operacje na tym agregacie.
Kolejna domena za modelowania za pomocą wzorców taktycznych i
strategicznych Domain Driven Design.
Proste modelowanie, a już po drzewie plików widać jak ta
domena jest ukształtowana.
Dużo łatwiej jest rozmawiać z biznesem projektując system w ten
sposób, niż sugerując się np.
architekturą warstwową, gdzie będziemy mieć przykładowo MVC
Model View Controller.
Biznes dużo łatwiej będzie rozumiał te wszystkie zależności.
Gdy pokażemy w ten sposób napisany kod, który operuje też zauważ
operuje też językiem biznesowym.
Nie ma tutaj zbyt wielu inżynierskich pojęć.
Są pojęcia dotyczące biznesu, w tym przypadku biznesu, prowadzenia
warsztatu samochodowego.