Ostatnia aktualizacja 20 listopada, 2023
Domain-Driven Design (DDD) to podejście do projektowania oprogramowania, które kładzie nacisk na zrozumienie i modelowanie przestrzeni problemowej. Najważniejszą rolę odgrywa tu zrozumienie języka domeny oraz współpraca z ekspertami domenowymi. W tym artykule skupimy się na trzech ważnych aspektach modelowania i designu w DDD: Event Stormingu, Ubiquitous Language (Wszechobecny język) oraz modelowaniu współpracy z użytkownikiem.
Event Stroming w DDD
Event Storming to technika warsztatowa, która służy do eksploracji i modelowania domeny problemowej. Proces ten umożliwia zidentyfikowanie kluczowych zdarzeń, procesów oraz aktorów w systemie. Tego rodzaju zmapowanie znacznie ułatwia komunikację między członkami zespołu i ekspertami domenowymi.
Podczas sesji Event Stormingu, uczestnicy, korzystając z kartek i markerów, mapują zdarzenia, komendy i agregaty na dużym obszarze (często na ścianie lub dużej tablicy). Ten wizualny sposób reprezentacji domeny jest niezwykle pomocny w identyfikowaniu luk, nieścisłości oraz w generowaniu nowych pomysłów.
Wyobraźmy sobie, że jesteśmy w zespole pracującym nad systemem zarządzania zamówieniami w sklepie internetowym. Ustaliliśmy, że chcemy zorganizować sesję Event Storming. Poniższa lista przedstawia przykładowe elementy, które mogą zostać zmapowane na ścianie lub dużej tablicy.
Aktorzy
- Klient
- Dział Obsługi Klienta
- Magazyn
- Dział Finansowy
Zdarzenia
Każdy etap zamówienia:
- Złożone
- Opłacone
- Spakowane
- Wysłane
- Dostarczone
- Anulowane
Komendy
Wszelkie komendy dotyczące zamówienia:
- Złóż
- Opłać
- Spakuj
- Wyślij
- Dostarcz
- Anuluj
Agregaty:
- Koszyk
- Płatność
- Paczka
- Wysyłka
Kiedy już mamy te elementy, uczestnicy (zarówno programiści, jak i eksperci domenowi) przyklejają kartki na ścianę/tablicę w logicznej kolejności, pokazując, jak te zdarzenia i komendy są ze sobą powiązane. Mogą także dodawać notatki i pytania, które pojawiają się w trakcie dyskusji.
Na przykład, po zdarzeniu “Zamówienie złożone” mogą nastąpić komendy “Opłać zamówienie” lub “Anuluj zamówienie”. Jeśli wybierze się “Opłać zamówienie”, to następuje zdarzenie “Zamówienie opłacone”, co z kolei uruchamia komendę “Spakuj zamówienie” w magazynie, i tak dalej.
W trakcie tej sesji uczestnicy mogą zidentyfikować luki w procesie (np. co się dzieje, jeżeli płatność nie dojdzie do skutku?) oraz nieścisłości w domenie (np. czy anulowanie zamówienia jest możliwe w każdym etapie?).
Ostatecznym celem jest stworzenie spójnego obrazu domeny problemowej, który pomoże nie tylko w implementacji systemu, ale także w jego dalszym rozwoju i utrzymaniu.
Dalsza część tekstu znajduje się pod materiałem wideo:
Ubiquitous Language w DDD
Wszechobecny język (Ubiquitous Language) to zbiór terminów i wyrażeń, które są zrozumiałe dla wszystkich członków zespołu projektowego oraz dla ekspertów domenowych. Celem tego języka jest zapewnienie spójności i jednoznaczności w komunikacji.
W DDD używa się wszechobecnego języka nie tylko w dokumentacji, ale także w kodzie. Ułatwia to zrozumienie domeny i niweluje potencjalne błędy. Stworzenie wszechobecnego języka wymaga bliskiej współpracy z ekspertami domenowymi, aby terminologia była jak najbardziej zgodna z rzeczywistością.
Modelowanie współpracy z użytkownikiem w DDD
Równie ważnym aspektem w DDD jest modelowanie interakcji i współpracy z użytkownikiem. Nie można zapomnieć, że ostatecznym celem każdego systemu jest dobre doświadczenie użytkownika. Dlatego też zrozumienie potrzeb, oczekiwań i ograniczeń użytkowników stanowi jeden z ważniejszych aspektów w projektowaniu.
Proces ten często wymaga użycia różnych technik, czyli historii użytkownika, scenariuszy czy prototypowania. Te elementy pomagają w lepszym zrozumieniu interakcji użytkownika z systemem i jakie funkcje są dla niego najważniejsze.
Koncepcja Bounded Contexts
Bounded Contexts odgrywa ważną rolę w organizowaniu i strukturyzowaniu logiki biznesowej aplikacji. Koncepcja opiera się na wyznaczeniu jasnych granic dla poszczególnych części modelu domeny, tak aby każdy fragment miał swoją unikalną odpowiedzialność i kontekst znaczeniowy.
Definiowanie Bounded Contexts wymaga ścisłej współpracy między programistami i ekspertami biznesowymi, aby dopilnować, że granice pomiędzy częściami modelu domeny są zrozumiałe i odzwierciedlają rzeczywiste potrzeby biznesowe. Zarządzanie Bounded Contexts obejmuje utrzymanie ich izolacji oraz zarządzanie zależnościami i interakcjami między nimi. Pomaga to w unikaniu problemów wynikających z wieloznaczności terminów i funkcji w różnych częściach systemu.
Dzięki wyraźnym Bounded Contexts, integracja systemów staje się bardziej przewidywalna i mniej podatna na błędy, ponieważ komunikacja między różnymi częściami systemu jest dokładnie zdefiniowana i ograniczona do ustalonych interfejsów. To podejście pozwala na bardziej efektywne zarządzanie złożonością systemów informatycznych i lepsze odzwierciedlenie poziomu skomplikowania rzeczywistego świata biznesu.
Czytaj także:
