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!
Serwis aplikacyjny to kolejny ważny wzorzec w Domain Driven Design.
Pomyśl o restauracji.
Restauracja składa się z wielu miejsc, wielu działów.
Jest kuchnia, jest sala, jest zaplecze.
Nad tym wszystkim czuwa manager, menadżer lokalu i ten menedżer koordynuje działanie
restauracji, często koordynuje zmiany kelnerów, koordynuje zamówienia.
Jest takim koordynatorem i takim managerem.
W aplikacji jest właśnie serwis aplikacyjny.
On też koordynuje różne części aplikacji, decyduje, jakim powinien
być flow wykonywania zadań.
Serwis aplikacyjny, co ważne, nie zajmuje się stricte logiką biznesową.
To jest rola agregatów serwisu domenowych.
Serwis aplikacyjny organizuje wykonanie logiki interakcji z
innymi częściami systemu.
On odpowiada za pobranie danych z bazy danych, zbudowanie obiektów np.
agregatów i wykonania na tych agregatach jakiejś operacji zapisania tych
agregatów z powrotem do bazy danych.
Jakie możemy mieć serwisy aplikacyjne?
Możemy mieć serwis zamówień, który będzie koordynował składanie zamówienia do
weryfikacji produktów, przetwarzanie płatności, aktualizacja
stanu magazynowego, wysyłkę.
Generalnie wykonuje wszystkie kroki w odpowiedniej kolejności i w odpowiedni
sposób, tak żeby zamówienie zostało złożone.
Inny przykład z aplikacji do zarządzania projektami może być serwis zadań, który
będzie zarządzał cyklem życia, zadania w projekcie będzie tworzył, przydzielał,
monitorował postępy, zamykał zadania, wysyłał powiadomienia, automatyzować
to wszystko i w aplikacjach bankowych.
Przykładem może być serwis transakcyjny, który odpowiada za przeprowadzenie i
rejestrację transakcji między kontami, czyli przelewy, walidację tych przelewów,
odpowiednia waluta, odpowiednie kwestie prawne zgodnie z
przepisami, zasadami banku.
Potem będzie aktualizował saldo, wysyłał powiadomienia, może generował jakieś
faktury, potwierdzenia przelewów.
A jak to może wyglądać to zapraszam Cię do kodu.
Taki prosty przykład z serwisu aplikacyjnego Place Order.
I widzisz, że tutaj mamy jakieś zależności w tym serwisie.
Mamy repozytorium, mamy jakiś serwis i co tu się może wykonywać?
Co tu się dzieje? Przejdźmy przez ten kod.
W pierwszej kolejności buduje nam się jakieś zamówienie.
Myślę, że to jest budowa obiektu zamówienia na podstawie
koszyka i ID klienta, więc mamy jakiś koszyk, jakiś obiekt koszyka i z tego
koszyka budowane jest zamówienie.
Więc dostajemy tutaj agregat np.
i mamy jakiś serwis płatności.
Mamy podsumowanie naszego zamówienia i chcemy zapłacić za to zamówienie.
Jeśli płatność się powiedzie, oznaczamy zamówienia jako zapłacone i
zapisujemy je do bazy danych.
Jeśli się nie powiedzie, oznaczamy zamówienie jako nie zapłacone z
niepoprawną płatnością, ale i tak je zapisujemy do bazy danych oraz wrzucamy
wyjątek, który może być obsłużony gdzieś na zewnątrz poprzez inną część systemu,
który powie nam, że zamówienie się nie powiodło.
Więc tu masz taki przykład tego, jak serwis aplikacyjny orkiestry je pracę,
więc wyciągamy, budujemy jakieś obiekty, możemy wyciągać rzeczy z bazy danych,
wykonujemy operacje i zapisujemy je.
To jest zero logiki biznesowej.
Mamy tutaj czysty flow orkiestracji, zarządzanie przepływem logiki, przepływem
informacji, komunikację między różnymi częściami systemu, między
różnymi częściami kontekstu.