Its Time To Ddd Duel

Myśl o Domain-Driven Design (DDD) jako o przewodniku, który pomoże Ci zbudować oprogramowanie idealnie dopasowane do problemu, który ma rozwiązywać. Zamiast budować ogólne rozwiązanie, skupiamy się na konkretnym obszarze biznesowym, czyli domenie.

Czym jest DDD? Wizualizacja kluczowych pojęć

Wyobraź sobie, że budujesz aplikację do zarządzania biblioteką. Twoją domeną jest "zarządzanie biblioteką". DDD pomoże Ci zrozumieć wszystkie aspekty związane z tą domeną, takie jak książki, czytelnicy, wypożyczenia, zwroty, katalogi, etc. Zamiast traktować to jako zbiór losowych danych, DDD pomaga nadać tym elementom strukturę i logikę.

Model Domeny - Mapa Twojego Świata

Model domeny to jak mapa Twojej domeny. To reprezentacja tego, jak działa Twój biznes. Pomyśl o mapie metra. Nie jest to dokładna kopia rzeczywistości, ale przedstawia kluczowe stacje (encje) i połączenia między nimi (relacje). W naszym przykładzie biblioteki, model domeny mógłby zawierać encje takie jak Książka (tytuł, autor, ISBN), Czytelnik (imię, nazwisko, numer karty), i Wypożyczenie (data wypożyczenia, data zwrotu, książka, czytelnik). Relacje między nimi określałyby, że czytelnik może wypożyczyć wiele książek, a każda książka może być wypożyczona przez wielu czytelników.

Język Ubiquitous - Wspólny język

Język Ubiquitous to słownik, który używasz Ty (programista) i eksperci od biznesu (bibliotekarze, kierownicy bibliotek). Wszyscy używają tych samych terminów, co eliminuje nieporozumienia. Wyobraź sobie, że budujesz most. Inżynierowie, architekci i budowlańcy muszą mówić tym samym językiem, używając precyzyjnych definicji "belki", "filara", "podporu". Podobnie, w DDD, jeśli bibliotekarz mówi "katalog", Ty jako programista wiesz dokładnie, o co chodzi, i używasz tego samego terminu w kodzie.

Bounded Context - Granice Odpowiedzialności

Bounded Context definiuje granice, w których dany model domeny ma zastosowanie. Wyobraź sobie mapę świata. Mapa polityczna (podział na kraje) różni się od mapy fizycznej (ukształtowanie terenu). Każda mapa ma swoje własne granice i skupia się na innym aspekcie. W naszym przykładzie biblioteki, możemy mieć jeden Bounded Context dla "zarządzania wypożyczeniami" i inny dla "zarządzania katalogiem książek". W kontekście "zarządzania wypożyczeniami" skupiamy się na tym, kto wypożyczył daną książkę i kiedy ma ją zwrócić. W kontekście "zarządzania katalogiem" skupiamy się na informacjach o książce, jej dostępności i przypisywaniu do kategorii. Książka w jednym kontekście może mieć nieco inną definicję niż w drugim.

Klocki DDD - Elementy konstrukcyjne Twojej Aplikacji

DDD ma kilka kluczowych "klocków" które wykorzystujesz do budowy oprogramowania.

Encje - Podstawowe Obiekty

Encje to obiekty z unikalną tożsamością. Jak ludzie. Dwie osoby o tym samym imieniu i nazwisku to nadal dwie różne osoby. W naszym przykładzie, Książka jest encją. Każda książka ma unikalny ISBN, który ją identyfikuje. Nawet jeśli mamy dwie książki o tym samym tytule i autorze, są to dwie różne encje.

Obiekty Wartości - Opisują Encje

Obiekty Wartości to obiekty, które identyfikujemy po ich wartości, a nie po tożsamości. Jak pieniądze. Dwa banknoty 10-złotowe są identyczne, o ile mają tę samą wartość. W naszym przykładzie, ISBN książki może być reprezentowany jako Obiekt Wartości. Dwa ISBN-y o tej samej wartości (np. 978-0321765723) są uznawane za identyczne, bez względu na to, w której encji Książka się znajdują.

Agregaty - Grupy Powiązanych Encji

Agregaty to skupiska powiązanych encji, które traktujemy jako jedną całość. Pomyśl o samochodzie. Ma silnik, koła, kierownicę, ale traktujemy go jako jeden samochód. W naszym przykładzie, Czytelnik i jego Wypożyczenia mogą tworzyć Agregat. Kiedy usuwamy czytelnika, automatycznie usuwamy wszystkie jego wypożyczenia. Agregat ma korzeń, czyli główną encję, która kontroluje dostęp do innych elementów agregatu. W tym przypadku Czytelnik jest korzeniem.

Repozytoria - Dostęp do Danych

Repozytoria to jak półki w bibliotece. Odpowiadają za przechowywanie i pobieranie encji. Umożliwiają dostęp do danych bez wnikania w szczegóły implementacyjne bazy danych. Używasz repozytorium, aby pobrać książkę po ISBN, zapisać nową książkę, albo znaleźć wszystkie książki danego autora. Są abstrakcją nad bazą danych.

Usługi Domenowe - Logika Biznesowa

Usługi Domenowe to operacje, które nie pasują do żadnej konkretnej encji lub obiektu wartości. Jak obsługa klienta w bibliotece. Na przykład, sprawdzenie dostępności książki (czy jest dostępna do wypożyczenia) może być usługą domenową, ponieważ obejmuje sprawdzenie stanu książki, liczby egzemplarzy i potencjalnych wypożyczeń.

DDD w praktyce - Krok po kroku

1. Poznaj Domenę: Spędź czas z ekspertami domenowymi (bibliotekarzami). Rozmawiaj z nimi, obserwuj ich pracę, zadawaj pytania. Używaj Języka Ubiquitous.

2. Zdefiniuj Bounded Contexts: Określ granice każdego kontekstu. Co należy do jakiego kontekstu?

3. Zbuduj Model Domeny: Zidentyfikuj Encje, Obiekty Wartości, Agregaty. Narysuj diagramy. Stwórz "mapę" Twojej domeny.

4. Implementuj Repozytoria i Usługi Domenowe: Zaimplementuj logikę dostępu do danych i logikę biznesową.

DDD nie jest srebrną kulą. Jest bardziej złożony niż standardowe podejście, ale w przypadku skomplikowanych domen, może przynieść ogromne korzyści w postaci lepiej zorganizowanego, łatwiejszego w utrzymaniu i bardziej elastycznego oprogramowania.