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!
I ostatni element z Domain Driven Design.
To jest kod infrastrukturalny.
Jeśli budujemy dom, to oczywiście interesujemy się tym, jakie
będą kolory ścian, jakie będziemy mieć umeblowanie, jak ten dom będzie wyglądał
i jaki będzie miał metraż.
Ale też istotne są rzeczy takie, których nie widać gołym okiem, czyli rozkład
kabli, kanalizacja, ogrzewanie. Tego nie widać.
To są takie rury, które gdzieś się tam ciągną.
Ogólnie infrastruktura, która umożliwia nam wygodne mieszkanie w budynku.
I czymś takim będzie kod infrastrukturalny.
To jest taki kod, który właśnie dba o te poboczne elementy.
Raz, że niezwiązane z logiką biznesową, dwa niezwiązane z przepływem programu, z
przepływem informacji w aplikacji, ale będzie zawierało wszelkiego rodzaju
integracje, cały potrzebny narzędziowy do tego, aby aplikacja działała i aby system
działał skutecznie, bo możemy tam znaleźć komunikację z bazami danych kolejki,
jakieś integracje integracja zewnętrzne.
To jest taki kod, który na pewno jest niewidoczny dla użytkownika końcowego,
więc będziemy mieć na przykład zastosowanie wzorca adapter, gdzie
będziemy mogli przepisać się między różnymi serwisami,
więc ten użytkownik końcowy nie będzie tak do końca wiedział, bo to logika
biznesowa nie będzie się zmieniać.
Kod infrastrukturalny to jest po prostu zestaw wtyczek, które umożliwiają nam
poprawne działanie całego systemu, ale z drugiej strony jest to niezbędne do
obsługi złożonych operacji i procesów w tle.
Cała infrastruktura naszej aplikacji przykłady takiego kodu np.
w aplikacji eCommerce to będzie wszelkiego rodzaju adaptery do bramek płatności,
obsługa kart, obsługa przelewów, rezerwacja hotelowych.
To może być np.
integracja z systemami rezerwacji, booking, WAGO itd.
Komunikacja z tymi systemami i ich synchronizacja kalendarza pomiędzy nimi.
Aplikacja do streamingu muzyki np.
może zarządzać treścią właśnie za pomocą tego kodu infrastrukturalnego.
Indeksować strumieniowania muzykę, kasować jakieś dostępy do biblioteki tak
aby aplikacja działała szybko, wygodnie i niezawodnie.
No i przykład taki w kodzie bardzo prosty, podręcznikowy to połączenie z bazą danych.
Mamy tutaj jakieś połączenie i to jest właśnie taki kod strukturalny, który tak
naprawdę nie wpływa na logikę biznesową.
Nieważne jaką tu mamy bazę danych.
Chodzi o to, żeby ta logika, ten kod, który tam pisaliśmy w poprzednich
punktach, żeby on zawsze działał i mamy jakąś konfigurację połączenia, ustalanie
połączenia z bazą danych tutaj wszystkie zmienne środowiskowe, dodatkowe pola,
konfiguracje, kod infrastrukturalny to wszystko to,
co nie mieści się w biznesie, w logice.
Wszelkiego rodzaju konfiguracje, adaptery, fasady do zewnętrznych
integracji, do narzędzi po prostu.
To są te wszystkie rzeczy, których nie widać gołym okiem, a dzięki którym system
będzie funkcjonował.