Zrozumienie biznesu to klucz do sukcesu programisty
1 godz. 30 min · Full-stack i Programowanie
Rafał PiekaraSoftware KomandosZgłębimy podstawy Domain Driven Design, skupiając się na zrozumieniu, czym jest domena i jakie role pełnią subdomeny w rozumieniu biznesu i projektowaniu oprogramowania. Dowiesz się, jak identyfikować i definiować domenę oraz subdomeny w kontekście biznesowym, co jest kluczowe dla efektywnego modelowania i implementacji systemów.
Skoncentrujemy się na jednym z kluczowych aspektów Domain Driven Design - definiowaniu granic kontekstów (Bounded Contexts). Nauczysz się, jak precyzyjnie wyznaczać te granice, co pozwala na lepszą separację i integrację różnych części systemu. Omówimy, jak wyznaczone granicę wpływają na jasność komunikacji w zespole oraz jak ułatwiają zrozumienie modelu biznesowego.
Spojrzymy na strategiczne wzorce DDD, skupiając się na kluczowych konceptach takich jak Subdomena i Bounded Context. Zrozumienie i umiejętność ich identyfikacji w strukturach biznesowych to podstawowa umiejętność w projektowaniu domenowym. Nie pominiemy też tematów pobocznych jak kontekst schizofreniczny czy Prawo Conwaya. Każdy z tych elementów pomoże Ci lepiej zrozumieć zastosowanie Domain Driven Design w praktyce.
Wzorce taktyczne są fundamentalne dla praktycznego modelowania i implementacji oprogramowania. O ile wzorce strategiczne wyrażają koncepcję, to wzorce taktyczne dotykają, tego, co kochają programiści i programistki czyli kodu. Zobaczysz jak i po co je stosować i jak mogą wspomagać spójność oraz transakcyjność danych.
Wszystko fajnie z tym DDD, ale jak to poukładać? Na to też znalazło się miejsce w kursie. Cały moduł poświęcimy na zapoznanie się z przykładową strukturą, organizacją plików i folderów aplikacji opartej o Domain Driven Design. Nie musisz się już zastanawiać, gdzie upchnąć Twoje klasy. Wszystko stanie się przejrzyste, intuicyjne i oczywiste.
Kurs powstał z myślą o programistach, architektach, liderach technicznych, a także ludziach biznesu, którzy potrzebują pogłębić swoją wiedzę o projektowaniu oprogramowania skoncentrowanego na domenie biznesowej. Niezależnie od tego, czy jesteś na początku drogi z DD, czy masz już trochę doświadczenia i chcesz usystematyzować lub odświeżyć wiedzę - ten kurs jest dla Ciebie!
A teraz agregat.
Można powiedzieć, że to kluczowy wzorzec w Domain Driven Design.
Agregat to coś w rodzaju pełnego worka pewnego pudełka, w którym kupujemy
całą logikę biznesową.
I to będzie tak jak z klockami Lego.
Kiedy budujemy jakąś budowlę z klocków Lego, moje ulubione Lego to są Star Wars.
To małe elementy tworzą większą, spójną całość.
Możemy wymieniać te elementy klocków, mamy ludziki, mamy
koła pojazdów, mamy platformy itd.
I dopiero zbiór tych wszystkich obiektów klocków Lego tworzy większą całość.
I co więcej te klocki Lego mają jeszcze pewien kontrakt, bo mają po prostu
wypustki, za pomocą których je zaczepiamy.
I to jest taki kontrakt, dzięki któremu tworzy się całość budowli.
I ten kontrakt.
Można powiedzieć, że są to pewne reguły biznesowe, reguły biznesowe
budowania budowli z klocków Lego.
I tutaj jeśli chodzi o agregat, będziemy mieć dokładnie tę samą symbolikę
w projektowaniu oprogramowania.
Agregaty będą traktowane jako jednostka modyfikacji danych, czyli strażniczki
strażnicy, a nie zmienników biznesowych.
Cały agregat będzie musiał być w spójnym stanie.
To znaczy, że wszelkie niezmiennie biznesowe reguły walidacji będą musiały
być spełnione, żeby agregat mógł być spójny, mógł być prawidłowo zbudowany.
Przykłady takich agregatów z różnych aplikacji, np.
e-commerce to będzie zamówienie, które będzie miało w sobie pozycję zamówienia,
informacje o kliencie, adres dostawy.
Te wszystkie informacje mogą być przechowywane w różnych tabelach.
Kojarzymy też z wzorców ORM np.
że tabele są mapowania do obiektów w kodzie.
Tutaj będzie inaczej.
Będziemy mieć agregat, który może się składać z kilku takich obiektów ramowych i
zmiany w zamówieniu będą zarządzane właśnie przez obiekt agregatu, a nie
będziemy aktualizować osobno informacji o kliencie np.
będziemy to robić przez sam agregat, aby zapewnić spójność całemu zamówieniu i
będziemy realizować reguły większej ilości modeli właśnie przez agregat zamówienia.
Inna branża bankowa to taki agregat może reprezentować konto bankowe, gdzie
będziemy mieć transakcje, operacje na koncie, wpłaty, wypłaty i inne tego typu
rzeczy i operacje realizowania przez obiekt konta czyli metody np.
Balance Credit Card itd.
I saldo konta takiego konta bankowego musi być zawsze w spójnym stanie.
Nie możemy zrobić przelewu z konta jeśli nie mamy włączonego np.
modułu debetowej, bo nie możemy przelać pieniędzy z konta, jeśli
nie mamy odpowiedniej kwoty.
I to wszystko będzie zawierała w sobie logika i walidację
agregatu konta bankowego.
Przesyłka magazynowa analogicznie będzie miała informację o produktach, ilości,
miejscu docelowym, statusie i zmiany statusu tej przesyłki będziemy
wykonywać właśnie przez agregat i agregat będzie wiedział w jaki sposób ta logika
zmiany statusu przesyłki powinna być zrealizowana.
Przejdźmy do prostego przykładu w kodzie to dwa klasyczne agregaty.
Agregat zamówienia z aplikacji e-commerce.
Podręcznikowy wręcz przykład.
Jak widzisz, zamówienie składa się z wielu pozycji w naszym zamówieniu.
Ma też pewien unikalny numer zamówienia, więc agregat może mieć też swój własny,
unikalny identyfikator, Ale nie musi.
Może, lecz nie musi.
Agregat to można powiedzieć, że jest taka bardzo rozbudowana encja lub
pewien kompozyt różnych encji.
I widzimy tutaj operacje na naszym agregacie możemy dodać nową pozycję
zamówienia, możemy dodać nową pozycję z parametrów i agregat wie o tym, że musi
sobie zbudować nowy obiekt order item.
Mamy tutaj też pewną logikę biznesową polegającą na wyliczeniu podsumowania
i pełnej kwoty zamówienia.
Tutaj ta logika może oczywiście być bardziej rozbudowana.
To jest bardzo podręcznikowy przykład, żeby pokazać, że nasz agregat
może mieć pewną logikę biznesową.
Ma też pewien stan, bo tutaj modyfikujemy stan tego agregatu i ma długi cykl życia.
I nasz agregat będzie ten stan zmieniał.
On zawsze musi być w spójnym stanie.
Można by tu dodać reguły walidacji, ale w każdym razie jest to pewien
kompozyt, pewna paczka zawierająca w sobie też inne mniejsze elementy.
I taki agregat kluczowy agregat dla naszego bound kontekstu
będzie się nazywał korzeniem agregatu czyli agregatu router i on może w sobie
też zawierać mniejsze agregaty tak jak tutaj.
Order item może być mniejszym agregatem i on też tu może mieć jakieś drobne
reguły realizacyjne, pewne elementy logiki biznesowej.
Agregat to jest taki stróż, strażnik nie zmienników biznesowych logiki biznesowej
w aplikacji według Domain Driven Design.