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!
No a teraz pora na przykłady kontekstu ograniczonego budżet kontekstu.
O ile subdomena dzieli logikę biznesową na zarządzane części na bazie takiej
kanwy konceptualnej, to budżet kontekst określa jak te części są
reprezentowane i implementowane.
I to już jest bardziej podejście implementacji.
Subdomena to koncept idea.
Definicja based context to implementacja, czyli inaczej mówiąc
obrócenie rąk w kodzie.
Jeśli chodzi o wspólne cechy subdomeny i kontekstu, bo bardzo łatwo tutaj
się pomylić lub zagubić w rozróżnieniu tych dwóch pojęć.
Tych dwóch definicji to zarówno subdomena, jak i bandit context
skupiają się na domenie, definiują pewien podział problemów, więc
pomagają nam podzielić problem na mniejsze zarządzane części.
Mają wpływ na architekturę, bo modelujemy nasz system dzieląc je,
dzieląc go na subdomeny i konteksty.
I przede wszystkim ułatwiają projektowanie i zarządzanie systemem.
Wydzielamy klocki, które mają bardzo jasną i określoną logikę.
Jakie są różnice między sub, domeną i budget kontekstem?
Przede wszystkim zakres.
Subdomena jest częścią domeny biznesowej, natomiast banner kontekst
dotyczy granic modelu domeny.
W implementacji blended context to nic innego jak klasy, serwisy,
struktury danych. Subdomena to zespół.
Zestaw pojęć, które będziemy stosować.
Funkcja Subdomena pomaga zrozumieć i podzielić złożoność biznesową,
pomaga nam zrozumieć biznes.
Natomiast based context zapewnia spójność modelu języka.
To jest już konkretna implementacja, konkretny kod, konkretny i
konkretna warstwa logiczna.
Zastosowanie Subdomena jest stosowana do identyfikowania obszarów biznesowych, do
modelowania biznesu, modelowania naszej logiki.
Natomiast bad kontekst bierze to, co sobie subdomena wymodelować, a co
wymodelować na bazie analizy.
I izoluje te modele i organizuje interakcje.
Ten kontekst definiuje, jak poszczególne modele, granice będą ze sobą rozmawiać,
jakie będą kontakty, jakie będą schematy danych, struktury, struktury tabel itd.
I wreszcie granice.
Granice Subdomena nie definiuje ścisłych granic technicznych.
Granice subdomen mogą się przenikać, subdomeny mogą się przenikać.
Natomiast bad kontekst wyraźnie określa granice techniczne modelu, wyraźnie
określa interfejs i kontakt.
Kontakt W jaki sposób komunikują się ze sobą inne konteksty?
A jak już mówimy o interakcjach, to subdomeny mają rozmyte granice,
mogą mieć rozmyte granice.
Ba, nawet kontekst ma jasne granice, jasno określoną komunikację, jasne określone
interfejsy do komunikacji i takie przykłady istnienia band
kontekstów w systemach.
System klasy eCommerce kontekst produktu, gdzie zarządzamy
informacjami o produkcie, kategoriami, cennikiem itd.
Kontekst zamówień.
Procesowanie zamówień.
Zarządzanie stanem zamówienia.
Obliczanie wartości zamówień.
Kontekst klienta.
Gdzie przechowujemy informacje o kliencie?
Historię jego zakupów.
Cały profil klienta.
Aplikacja w domenie HR to może być kontekst rekrutacji, gdzie zarządzamy
procesem rekrutacji i kandydatami.
Kontekst zarządzania pracownikami, czyli dane pracowników, urlopy, rozwój kariery
to wszystko już w formie implementacji.
Płace obliczanie wynagrodzeń już tutaj Kalkulacja,
zarządzanie, benefity komu jakie benefity należy przypisać?
No i mamy kontekst bankowy.
Mamy kontekst kont bankowych, gdzie zarządzamy kontami, sadami.
Kontekst kredytów, ocena zdolności kredytowej, zarządzanie umowami
kredytowymi, inwestycje, zarządzanie portfelami inwestycyjnymi, doradztwo.
Wszelkie tego typu rzeczy już w formie implementacji np.
aplikacja dotycząca opieki zdrowotnej, gdzie możemy mieć kontakt pacjenta, czyli
przechowywanie historii medycznej, planowanie wizyt, kontakt szpitala To już
jest logistyka, czyli zarządzanie, tak jak to było w kontekście e-commerce.
Mieliśmy magazyn, to mamy szpital, logistyka, zarządzanie personelem,
sprzęt, ubezpieczenia zdrowotne.
Tutaj w tym kontekście możemy rozliczać polisy, roszczenia, zarządzanie ryzykiem,
usuwanie polis, rozszerzanie tych polis.
To wszystko może być właśnie w ramach kontekstu, więc już tutaj
mówimy o bardzo konkretnych regułach, konkretnych granicach i
konkretnej implementacji.