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!
Język wszechobecny to polskie tłumaczenie pojęcia UPS language, które jest podstawą
efektywnego wdrożenia Domain Driven Design.
To jest ten język, o którym mówiłem.
Ten wspólny język, rozumiany tak samo przez programistów, jak i przez biznes.
Jest to swego rodzaju wspólna terminologia, zakres pojęć, współdzielone
słownictwo, które jest używane przez wszystkich członków zespołu, jest używane
i rozumiane tak samo.
To może być słownictwo techniczne lub też nie techniczne i język wszechobecny.
KJS Language jest odwzorowaniem domeny.
Domena wyraża się w tym języku.
Domena wyraża się w tej terminologii, w tych pojęciach i reguły biznesowe
będą wyrażone w tym języku.
Po co jest konieczne wypracowanie takiego wspólnego języka?
Jest to wspólny język, który wypracowuje się drogą komunikacji, drogą warsztatów,
drogą definiowania interakcji między programistami a biznesem.
I po co jest ten język?
Ten język eliminuje błędy komunikacyjne.
Standardowym przykładem jest pojęcie usera.
User dla modułu logowania jest zupełnie czymś innym niż user dla modułu Delivery,
który dla którego user nie jest tak naprawdę użytkownikiem systemu, ale jest
odbiorcą przesyłki, odbiorcą paczki i modułu Delivery tak naprawdę nie
interesuje e-mail użytkownika i wszelkiego dane interesuje tylko jego adres.
Podczas gdy moduł logowania interesuje się hasłem, interesuje się emailem, interesuje
się danymi potrzebnymi do autentykacji i prawidłowe rozumienie tego hasła, tego
pojęcia pomiędzy różnymi kontekstami w domenie jest właśnie domeną
języka wszechobecnego.
Język ten jest używany tak przez biznes, jak i technologie.
Obie te strony używają tych samych pojęć i tych samych.
Te same pojęcia rozumieją w taki sam sposób.
Język wszechobecny wpływa na model domenowe i model nowy.
Nowy jest definiowany właśnie za pomocą tego języka i tych pojęć.
I język ten ewoluuje też razem z domeną i z projektem, tak jak
zmieniają się wymagania.
Może się zmienić też znaczenie pojęć.
Znaczenie sformułowań i pewne hasła będą już inaczej rozumiane po jakimś czasie
istnienia projektu niż to było na początku i język na końcu wreszcie
wymusza współpracę.
Żeby zdefiniować język, zdefiniować terminologię i jednoznacznie jasno
określone, wspólnie brzmiące pojęcia, konieczna jest współpraca pomiędzy
zespołami, pomiędzy ludźmi w zespole, pomiędzy stronami, w projekcie, które
razem współpracują nad tym, żeby zdefiniować ten właśnie wspólny
język wszechobecny UBG Language.