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!
Jeszcze krótko o kontekście schizofreniczny.
W realnych przykładach kontekst schizofreniczny charakteryzuje
się tym, że nie ma.
Nie mamy zdefiniowanych wyraźnych granic i te konteksty gdzieś
przenikają, one się rozmywają.
I tak w domenie e-commerce możemy mieć kontekst produktu, który
definiuje nam produkt jako towar i jako cyfrową pozycję w magazynie, jako element
inventory, element inwentarza i będziemy mieć konflikt między działem sprzedaży a
magazynem i zamieszanie w zarządzaniu zapasami, sprzedażą,
marketingiem, wysyłce itd.
Pojęcie produktu będzie różnie rozumiane.
Nie ma jasnej definicji albo korzystamy np.
z tej samej tabeli w bazie danych, która przyjmuje zbyt dużo
właściwości, ma zbyt dużo kolumn, bo zbyt wielu różnym kontekstem ona odpowiada.
W aplikacji dotyczącej zarządzania projektami możemy mieć taki kontekst
zadania, który jest interpretowany i definiuje nam zadanie jako
jednostkę pracy lub cele projektu.
Będziemy mieć wtedy pewną niejednoznaczność w komunikacji między
zespołami technicznymi i zarządem management.
I to może wpływać na planowanie, zarządzanie zasobami, raportowanie i
definiowanie momentu zakończenia projektu.
W aplikacjach bankowych może być kontekst konta, który definiuje pojęcie konta jako
profil użytkownika i rachunek finansowy i nie będziemy wiedzieć, o jakim koncie
rozmawiamy, jakie konto jest przekazywane jako parametr w naszej klasie i pojawi się
nieścisłość w obsłudze klienta i zarządzaniu finansami tego klienta.
Mogą być problemy z integracją między systemami, zarządzaniem ryzykiem, obsługą
klientów, obsługą kontaktu z aktualizacjami kont, procesowania
transakcji i wreszcie np.
w aplikacji z branży opieki zdrowotnej może mieć kontakt pacjenta, który będzie
osobą, czyli po prostu profilem użytkownika lub przypadkiem medycznym.
Przypadek medyczny, który jest anonimowy i będziemy mieć tutaj inne podejście
między opieką medyczną, administracją dla administracji pacjent będzie np.
płacącym klientem kliniki, natomiast dla lekarza w opiece medycznej pacjent będzie
jakimś zbiorem cech i zdarzeń, które doprowadziły do
określonego stanu zdrowia i może dojść do komplikacji w zarządzaniu danymi,
planowaniu opieki i rozliczaniu ubezpieczeń.
Trzeba bardzo uważać na kontekst schizofreniczny.
Ale wiesz już, jak definiować granice kontekstów.
Masz te pewne heurystyki, te pewne podpowiedzi, które Ci przekazałem
wcześniej, więc myślę, że po tej lekcji będzie Ci łatwo wychwycić, kiedy taki
kontekst schizofreniczny zaczyna się pojawiać i wtedy łatwo można
zdefiniować prawidłowe granice, właśnie posługując się tymi heurystyka.