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!
Powiedziałem już.
Objects to takie proste obiekty, które mają jakąś wartość, nie mają raczej
zachowań i implementują metodę porównań.
Więc w jaki sposób można testować value obiekty w kodzie?
Możemy przede wszystkim testować konstruktory, więc sprawdzać, czy value
object zostanie zainicjowany z odpowiednimi wartościami i czy poprawnie
zajdzie przypisanie wartości do pól lub zajdzie jakakolwiek walidacja.
Możemy testować równość, więc implementację samej metody porównywania
oraz wszystkie scenariusze, w których obiekty z tymi samymi wartościami
są równe lub się będą różnić.
Będziemy też testować niezmienność, więc jest to ważne, żeby zapewnić value
obiektom, że nie mogą być zmieniane po utworzeniu i że modyfikacja
zawsze zwróci nam nowy obiekt.
Więc będziemy tutaj testować Hash Code Object ID w zależności od tego
jaki język będziemy stosować.
No i wreszcie możemy też testować wyjątki.
A więc w momencie kiedy podamy jakąś nieprawidłową wartość lub próbujemy
zainicjować wywali objects.
Nieprawidłową wartością powinien być rzucony wyjątek.
Powalił Object.
Nie może istnieć w niepoprawnym stanie, w nie spójnym stanie.
Wali Object jest zawsze poprawny.
Przejdźmy teraz do kodu i zobaczmy jak wyglądają przykładowe
testy value obiektów.
Tutaj mamy test obiektu Adres Co tutaj testujemy?
Testujemy, czy poprawnie zostaje utworzony nowy obiekt adresu, więc
przekażemy odpowiednie parametry.
To czy faktycznie pola tego obiektu przyjmą te parametry?
I testujemy tutaj metodę porównania.
Mamy dwa adresy o tych samych wartościach ta sama ulica, to samo miasto
i sprawdzamy czy te adresy są równe.
Value Object email Email testujemy w ten sam sposób, więc
będziemy tutaj testować czy zostaje poprawnie stworzony Value
Object, ale przetestujemy też rzucenie wyjątku.
Jeśli podamy zły adres email, złą wartość, to powinniśmy otrzymać wyjątek.
No i testujemy porównywanie czy dwa adresy email faktycznie będą równe.
No i test obiektu pieniędzy obiektu manii, gdzie testujemy inicjalizacja tego
obiektu, więc sprawdzamy czy currency i kwota są takie same.
I w momencie gdy mamy dwa obiekty mani z tą samą kwotą i tą samą
walutą powinny one być równe.
Bardzo proste testy.
Jak widzisz Value Object i Ty to dość prosty koncept i testowanie tych
obiektów też jest niezwykle proste, jeśli używamy ich w systemie.
W wielu miejscach taki obiekt definiujemy raz testy piszemy raz i one już nam
gwarantują poprawność i spójność w naszym systemie, że te value obiekty, obiekty,
wartości będą zawsze spójne i będą prawidłowo implementować swoje metody.