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!
Idąc krok dalej przechodzimy do drugiego wzorca taktycznego Domain
Driven Design do encji.
Czym jest encja?
Wyobraź sobie, że masz kilka kart bankowych z tego samego banku.
Masz kartę kredytową debetową, kartę do konta dolarowe, do konta w euro, do konta
w złotówkach, kartę do konta prywatnego i kartę do konta biznesowego.
Mimo, że są to karty z jednego banku, mimo że każda z tych kart mogłaby mieć na sobie
to samo saldo, to będziemy szukać ich różności przez unikalną tożsamość.
Innymi słowy, encja, które jest, będzie reprezentacją karty kredytowej.
Encja to taki obiekt, który ma unikalną tożsamość.
Najczęściej tą unikalną tożsamość wyrażamy za pomocą oczywiście pola id lub
Unique id UUID.
I nawet jeśli te encje będą przechowywać te same informacje, te same wartości, to
nie interesuje nas tutaj porównywanie jeśli chodzi o wartości.
Ale będziemy porównywać czy te encje mają ten sam identyfikator.
Jeśli mają ten sam identyfikator to są te same obiekty.
Jakie mogą być reprezentacje encji w kodzie biznesowym?
To może być konto bankowe, gdzie będzie ten unikalny identyfikator
w formie numeru konta, a wartości, które będziemy mieć to może być saldo,
może być historia transakcji.
Tak samo w produkcie w aplikacjach e-commerce.
Mamy taki atrybut, który jest tym indywidualnym identyfikatorem dla
produktu, a różnić się mogą nazwą, ceną, opisem.
To nas nie interesuje.
Tak samo w zamówieniu będziemy mieć unikalny numer zamówienia, a lista
produktów, data zamówienia czy status to będą tylko wartości poboczne.
Zamówienia będą tożsame, jeśli będą mieć ten sam numer.
Przejdźmy teraz do kodu.
Przygotowałem dla Ciebie prosty przykład.
Jest to encja usera.
Jak widzisz oba te kody i w drugim i w tym skrypcie mają te same pola name, email
i id które są ustawiane w konstruktorze.
Mamy tutaj jakieś transformacje tego kodu do JSON a.
Mamy tutaj podobnie transformację z Jasona,
więc mamy parsowanie i realizację, ale też mamy
metodę, która zmieni stan tej encji, zmienia email
tak w skrypcie jak i w routing, więc encja ma jeszcze drugą wartość.
A Encja ma jakiś cykl życia, ma jakiś stan, który się zmienia w trakcie.
Jest to prosty obiekt.
On przypomina taki rekord po prostu znany z innych języków, ma unikalny
identyfikator i ma jakiś cykl życia, czyli może zmieniać stan, może zawierać jakieś
elementy logiki biznesowej, które dotyczą samej tej encji.
Więc to jest encja.
Zapamiętaj Najważniejsza rzecz encji to jest unikalny identyfikator.
Encje różnią się identyfikatorami, nie wartościami.