Cześć 

Jest to trzeci wpis z serii o DDD. Dziś porozmawiamy o tym czym jest Bounded Context (BC).

W dzisiejszym artykule:

• Zrozumieć Bounded Context
• Subdomena vs Bounded Context
• Przykład BC

Zrozumieć Bounded Context

Czym jest Bounded Context (BC)? Tłumacząc to bezpośrednio na nasz polski język to jest to Ograniczony kontekst. Prawdę mówiąc to, ta translacja jest w 100% poprawna. Ale jeżeli jesteś nowy w DDD i pierwszy raz słyszysz o BC, to możesz się zastanawiać co w rzeczywistości oznacza ograniczony kontekst?

Bounded Context definiuje granice podsystemu. Zawiera swój model domenowy i co jest bardzo ważne nie współdzieli danych modelu z innym kontekstami. W praktyce oczywiście jest tak, że różne Bounded Context’y muszą komunikować się ze sobą. Komunikacja taka nie jest niczym złym – bez tego nasze oprogramowanie miałoby ciało ale nie miało przykładowo rąk czy nóg, innymi słowy – nie działałoby jako całość. BC komunikują się między sobą przez jasno zdefiniowane API.

Razem z pojęciem BC często pojawia się także pojęcie Ubiquitous Language (wszechobecny język). Oznacza ono, używanie wspólnego języka w danym podsystemie przez wszystkich. Kim są wszyscy? Ludzie od biznesu, product owner, scrum master, developerzy – wszyscy, którzy pracują w danym podsystemie.

Język ten jest platformą komunikacji pomiędzy tymi wszystkimi ludźmi – tylko trzeba pamiętać – w ramach danego bounded context’u. Jak jest to przedstawione na obrazku wyżej, Produkt w kontekście Shopping Context będzie charakteryzował się innymi właściwościami niż ten w Offers Context. W ofercie ważne będzie podkreślenie jego charakterystycznych cech np. w czym pomoże potencjalnemu użytkownikowi oraz jaka jest jego cena. W kontekście sprzedaży cena również będzie ważna ale dodatkowo istotne będzie czy produkt jest dostępny i można go kupić. W kontekście samego produktu istotne może być np. moment dodania produktu do sklepu czy też ilość produktu w magazynie. Dodatkowo, z czasem język może ewoluować. Eksperci domenowi mają większą wiedzę, wymagania biznesu się zmieniają lub po prostu dochodzą nowe.

Subdomena vs Bounded Context

Nie będę się specjalnie rozpisywał w tej sekcji.

Najważniejsza różnica pomiędzy obiema definicjami jest taka: subdomena opisuje problem a bounded context jest jego rozwiązaniem. Subdomeny odkrywamy a bounded context definiujemy. Jest to po prostu przełożenie wszystkich informacji jakie do tej pory zebraliśmy na model. Model, który za pomocą wszechobecnego języka definiuje zachowanie konkretnego bounded context’u.

Przykład BC

Przykład został zaczerpnięty z dokumentacji MS i nieco zmodyfikowany.

Scenariusz: Usługa dostaw przy pomocy dronów.
Firma XYZ uruchamia usługę dostaw przy pomocy dronów. XYZ zarządza całą flotą dronów.  Jej użytkownicy mogą poprosić o drona do odbioru towaru. Kiedy klient planuje odbiór, system backendowy przydziela drona i powiadamia użytkownika o przewidywanym czasie dostawy. W trakcie realizacji dostawy klient może śledzić lokalizację drona, dzięki stale aktualizowanemu systemowi. XYZ pozwala również na usługi firm zewnętrznych – firma chcąca być podwykonawcą rejestruje się w serwisie i również może dostarczać przesyłki. Z punktu widzenia klienta końcowego usługi nadal są świadczone przez firmę XYZ.

Analiza:

Problem opisany powyżej można podzielić na kilka subdomen (nie wszystko zostało ujęte w scenariuszu):

Shipping – jest umieszczony w centrum diagramu, ponieważ jest to rdzeń biznesu.
Zarządzanie Dronami – również jest podstawą działalności firmy. Funkcjonalność, która jest ściśle związana z zarządzaniem dronami, obejmuje naprawę dronów oraz wykorzystanie analizy prognostycznej do przewidywania, kiedy drony będą wymagały obsługi i konserwacji.
Analiza ETA – umożliwia oszacowanie czasu odbioru i dostawy.
Third party – umożliwia aplikacji planowanie alternatywnych metod transportu, jeżeli paczka nie może być wysłana w całości przez drona.
Dzielenie dronów – jest możliwym rozszerzeniem podstawowej działalności. Firma może mieć nadmierną pojemność dronów w określonych godzinach i może wynajmować drony, które w przeciwnym razie pozostałyby bezczynne. Ta cecha nie pojawi się w początkowym wydaniu.
Nadzór wideo – to kolejny obszar, w którym firma może rozwinąć się później.
Konta użytkowników, fakturowanie i call center to subdomeny, które wspierają podstawową działalność firmy.

Teraz, mając już zdefiniowane subdomeny naszego problemu możemy przejść do definiowania Bounded Context’ów (BC’s).

Modelem, znajdującym się w centrum domeny jest model drona. Obojętne z jakiej subdomeny spojrzysz na projekt – dron jest w jego centrum. Zarządzanie dronami (Drone Management) będzie definiowało historię konserwacji, przebieg, rocznik, numer modelu, itd. Ale kiedy jest czas na zaplanowanie dostawy, nie dbamy o te rzeczy. Podsystem planowania musi tylko wiedzieć, czy dron jest dostępny oraz jaki jest przewidywalny czas odbioru i dostawy.

Idąc starym podejściem (moim zdaniem biorącym się z chęci szybkiego dostarczenia wartości i braku myślenia nad tym co robimy) po 3 miesiącach pracy mogłoby się okazać, że nasz model wyglądałby w taki sposób:

class Drone {
    // Drone Management
    MaintenanceHistory maintenanceHistory;
    int mileage;
    int age;
    String modelNumber;

    // Shipping
    boolean isAvailable;
    LocalDateTime pickUp;
    LocalDateTime delivery;
    
    // pozostale sub-domeny
    //...
}

Do czego to końcowo doprowadzi? Do kodu, który jest

1. Nieutrzymywalny – dodanie czegoś nowego / modyfikacja istniejących właściwości to zmora i tylko pogłębienie problemu.
2. Trudny w zrozumieniu – jak wejdzie ktoś nowy na projekt, to chcąc nie chcąc musisz wytłumaczyć mu działanie wszystkiego co kręci się wokół modelu drona, inaczej może tylko dodatkowo nabałaganić.

Jak można rozwiązać ten problem? Wprowadzając BC! Po pierwsze trzeba zastanowić się jak zdefiniować granice pomiędzy sub-domenami. Mogłoby to wyglądać następująco:

I teraz najistotniejsze. Chcemy aby nasz model drona był czymś innym w zależności od tego w jakiej sub-domenie się znajdujemy! Czyli zamiast jednego wielkiego modelu będziemy mieli kilka innych! Takich, które będą odpowiadać tym właściwościom jakie są wykorzystywane w konkretnej sub-domenie.

// Drone Management
class Drone {
    MaintenanceHistory maintenanceHistory;
    int mileage;
    int age;
    String modelNumber;
    
    // metody specifyczne do wykonania w tej domenie
    // ...
}

// Shipping
class Drone {
    boolean isAvailable;
    LocalDateTime pickUp;
    LocalDateTime delivery;

    // metody specifyczne do wykonania w tej domenie
    // ...
}

W taki sposób definiujemy zachowania i właściwości specyficzne dla danego Bounded Context’u. Zwiększamy również czytelność i możliwość łatwiejszego wdrożenia nowych osób. Nowa osoba nie musi już wiedzieć wszystkiego o wszystkim. Jeżeli ma zająć się sub-domeną zarządzania dronami to wystarczy jej wiedza w obrębie tego konkretnego modelu.

Podsumowanie

Bounded Context (ograniczony kontekst) nie jest czymś specjalnie trudnym do zrozumienia. W nowych projektach, gdzie mamy okazję modelować subdomena – bounded context  w relacji 1:1 wszystko wydaje się być łatwe. Problem pojawia się kiedy wchodzimy w świat legacy (lub sami go tworzymy) i okazuje się, że nie jest już tak idealnie. Nasz bounded context zaczyna rozwiązywać problemy z kilku domen a po kilku miesiącach zostaje już tylko context – bounded zostało zjedzone.

Oczywiście tak nie musi być :). Jako programiści / architekci musimy zawsze czuwać nad kodem i myśleć jaki wpływ będzie mieć zmiana, którą właśnie implementuję. Niestety, z doświadczenia wiem, że biznes chce wszystko na już i niespecjalnie daje nam czas na zastanowienie się nad kodem. Co robić w takich sytuacjach? Może to zabrzmi arogancko ale.. nie zawsze spełniać na hura zachcianki klienta. Ile razy spotkałeś się, że klient coś chciał a za miesiąc się rozmyślał? Mi kilka razy się zdarzyło…

Źródła:

• BoundedContext
• Define bounded contexts
• Kurs DNA

Za tydzień

Chcę poruszyć swoje indywidualne kwestie – tak jak zrobiłem to w tym wpisie. Właściwie, to wydaje mi się to dobrym pomysłem żeby robić takie comiesięczne podsumowania + przemyślenia co dalej.

Artykuł Bounded context w DDD 👀 pochodzi z serwisu bdabek.pl.

Cześć 

Jest to drugi wpis z serii o DDD. Dziś zdefiniujemy domenę oraz naprowadzę Cię jak możesz ją poznawać.

W dzisiejszym artykule:

• Domena – czym jest?
• Rodzaje domen
• Jak odkrywać domenę?

Domena – czym jest?

Aby odkryć domenę na początku dobrze byłoby ją zdefiniować. Według słownika PWN

zakres zainteresowań lub działalności jakiejś osoby, instytucji lub dziedziny wiedzy

– Słownik PWN

A według bardziej programistycznych forów (SO i SE):

Domena odnosi się do konkretnego tematu, dla którego projekt jest opracowywany. Jest przestrzenią problemową, którą należy rozwiązać projektując oprogramowanie.

Czyli w prostych słowach – domena reprezentuje problem do rozwiązania.

Rozważmy metaforę producenta statków. Statek może składać się z setek tysięcy części, a pracownicy pracujący nad jego rozwojem nie mają pełnego kontekstu całej produkcji wymaganej do budowy statku ze względu na jego skalę. Pracownicy koncentrują się na jednym konkretnym obszarze statku i wykonują go, podczas gdy inni pracownicy pracują równolegle na innych częściach. Postęp zachodzi jednocześnie. Pracownik, który pracuje z tyłu statku, nie musi dokładnie wiedzieć, jak postępują prace z przodu, ponieważ wykracza to poza jego zakres i nie wpłynie na wykonywaną przez niego pracę.

Są jednak osoby, które mają za zadanie wiedzieć jaki jest dokładny stan produkcji statku z szerszej perspektywy. Osoby te mają lepszy przegląd pełnego postępu, ale nie muszą znać dokładnej szczegółów implementacji, ponieważ do tego wymagana jest konkretna wiedza. Są również osoby, które znają się doskonale właśnie na szczegółach, jak np. budowa kadłubu czy instalacja silników. Na każdym poziomie wymagana jest nowa wiedza, aby zrozumieć granice wykonywanej pracy i jak ją wykonać.

Jak więc poznać domenę? Angażując specjalistów, ekspertów danej dziedziny, ludzi, którzy faktycznie mają wiedzę o tym, dlaczego podejmujemy decyzje, które podejmujemy. Są to ludzie, którzy będą przekazywać wiedzę, która ostatecznie będzie odzwierciedlać podstawowe elementy domeny, aby stworzyć dobre oprogramowanie. Aby domena była dobrze odwzorowana w kodzie musisz ją poznać, zrozumieć i zamodelować.

Zauważ, że produkcja statku nie jest trywialnym procesem. Składa się z wielu odrębnych domen (dziedzin). Na pewno każdy z elementów jest istotny jednak często bywa tak, że niektóre domeny są ważniejsze od innych. Z tego powodu domeny można podzielić na trzy rodzaje.

Rodzaje domen

W przypadku złożonych domen – a zazwyczaj takie chcemy odkrywać i modelować – często okaże się, że tylko konkretna subdomena jest istotna z biznesowego punktu widzenia. Inne również są ważne i być może bez nich nasza główna domena nie miałaby sensu. Nie są one jednak aż tak istotne i nie musimy wkładać w nie tyle uwagi i poświęcenia.

Domeny możemy podzielić na 3 rodzaje:

• główna (core domain) – najważniejsza część systemu. Dzięki niej biznes odnosi sukces i ma przewagę nad konkurencją. Odpowiada na pytania dlaczego powstaje (powstał) dany system i dlaczego go nie kupiliśmy.
• wspierająca (supporting domain) – zapewnia funkcje wspierające domenę główną. Nie zapewnia żadnej przewagi konkurencyjnej bez obecności core domain. Nie istnieje gotowy produkt by je dostarczyć ze względu np. na specyfikację naszej domeny głównej.
• generyczna (generic domain) – zapewnia ważne funkcje dla działania biznesu ale nie są one unikalne i istnieją już gotowe rozwiązania. Np. wysyłka maili czy też usługa monitorowania.

Jak odkrywać domenę?

Nie jestem ekspertem w tej działce. Dlatego lepiej będzie jak po prostu powiem krótko o istnieniu czegoś takiego jak Event Storming. Jest to metoda odkrywania i konkretyzowania informacji o domenie biznesowej. Jest chyba najpopularniejszą formą odkrywania domeny. Wymaga zaangażowania co najmniej kilku osób – ekspertów. Ekspertów znających się na problemie jaki rozwiązujemy od strony biznesowej. Przy ich pomocy jesteśmy w stanie utworzyć mapę problemu jaki rozwiązujemy. Rozpisać występujące zdarzenia, przypisać ich aktorów oraz rozdzielić na odpowiednie subdomeny.

Przy pomocy event stroming’u jesteśmy w stanie:

• zrozumieć domenę
• poznać język biznesowy
• zidentyfikować problemy (znane lub nieznane do tej pory)
• znaleźć subdomeny

Więcej na temat Event Stromingu możesz przeczytać w tym artykule.

Podsumowanie

Dlaczego odkrywanie domeny jest ważne? Po pierwsze – rozumiemy działania biznesu, znamy kontekst, wiemy dokąd zmierzamy. Dwa, jesteśmy w stanie podzielić problem na mniejsze problemy a co za tym idzie zrównoleglić prace. Trzy – po podzieleniu problemu na mniejsze możemy nadać im odpowiedni priorytet decydując co jest najistostniejsze dla biznesu a co można outsourcować z zewnątrz.

Źródła:

• Part 1: Domain Driven Design like a pro
• Kurs DNA

Za tydzień

Zajmiemy się definicją bounded contextów oraz tego jak to się ma do subdomen.

Artykuł Domena w DDD. Jak ją poznać ❓🤔 pochodzi z serwisu bdabek.pl.

Cześć 

Techniki DDD zyskały swą popularność w roku 2003, wraz z publikacją książki Erica Evansa. Mimo upływu lat koncepcja DDD jest wciąż żywo rozwijana i wzbogacana o nowe techniki.

W dzisiejszym artykule:

• Zrozumieć DDD
• Podstawowe koncepty DDD
• Trudności związane z DDD

Zrozumieć DDD

Domain Driven Design jest zestawem technik i koncepcji służących do projektowania złożonych modeli biznesowych i ich dosłownej implementacji. Naszym zadaniem, jako programistów jest zrozumienie faktu, iż technologia w jakiej rozwiązujemy problem nie jest istotna. Nasza uwaga powinna skupiać się na biznesie. Dążymy do zrozumienia wartości biznesu, tego co robimy i w jaki sposób przekłada się to na $.

Fundamentalnym zagadnieniem DDD jest relacja biznes <=> zespół. Kod, wytwarzany przez zespół musi opierać się na domenie w jakiej pracujemy. Każda domena ma jakieś reguły, walidacje, kompromisy – generalnie zasady biznesowe. I tu pojawia się pierwsza ściana – musimy poznać domenę. W jaki sposób poznaje się domenę opiszę w kolejnym artykule – na dziś niech wystarczy Ci wiedza, że musisz znaleźć osobę / osoby, które bardzo dobrze znają problem od strony biznesu.

Tak jak na obrazku powyżej – domena będzie się zazwyczaj składała z kilku subdomen. Podczas odkrywania domeny z biznesem będą pojawiały się zarysy, które na podstawie doświadczenia / przeczucia / konsultacji z innymi będziesz definiował.

A zatem jak rozumieć Domain Driven Design? Wyróżniłbym tutaj 3 główne zasady, DDD:

• koncentruje się na podstawowej domenie i logice domeny
• opiera złożone projekty na modelach domeny (to domena jest najważniejsza)
• polega na współpracy z ekspertami dziedzinowymi w celu ulepszania modelu aplikacji i rozwiązywania wszelkich pojawiających się problemów związanych z domeną

Podstawowe koncepty DDD

Kiedy czytamy o DDD na pewno spotkamy się z pojęciem Ubiquitous Language. W praktyce oznacza to wspólny język modelu, którym posługuje sią cały zespół, począwszy od eksperta domenowego po programistów warstwy logiki domenowej. Jest to przy okazji jedna z zalet aplikacji opartych o projektowanie domenowe.

Innym konceptem są Bulding Blocks, czyli język standardowych wzorców, z których budujemy modele. Tutaj pozwolę sobie skopiować część artykułu bottegi, która jest zresztą doskonałą lekturą DDD (w większość konceptów wejdziemy z czasem):

• Entity – identyfikowalne obiekty zawierające odpowiedzialność biznesową;
• Aggregate – hermetyczne grafy obiektów, z jedną encją będącą „korzeniem agregatu”, która stanowi API całości. Agregat jest główną jednostką logiki domenowej w DDD;
• Value Object – wrapper dla typów prostych, nadający im znaczenie biznesowe oraz wygodny interfejs;
• Service – specyficzne operacje, które nie pasują do żądnego agregatu;
• Policy – model wariacji operacji biznesowych, Strategy Design Pattern;
• Specification – model złożonych warunków biznesowych, wywodzi się z Composite Design pattern;
• Event – model wydarzeń biznesowych, może służyć do przetwarzania równoległego lub komunikacji pomiędzy Bounded Context;
• Saga – model złożonego procesu, który stan jest trwały oraz zależy od wielu zdarzeń;
• Factory – tworzy nowe instancje złożonych Agregatów, dbając o ich poprawność. Zwiększa testowalność, biorąc niejako na siebie operatory new;
• Repository – zarządza trwałością Agregatu/Encji.

Trudności związane z DDD

Podstawowym problemem jest komunikacja i znalezienie eksperta domenowego. Jeżeli takiej osoby nie ma to nic nie wyczarujemy. Możemy zgadywać jak ma wyglądać domena ale to nie jest dobre rozwiązanie. Prędzej lub później okaże się, że pomyliliśmy koncept i nie o to chodziło biznesowi – a wtedy zmiany mogą być bolesne…

Kolejną trudnością są kompetencje zespołu developerskiego. Jeżeli żaden z programistów całkowicie nie wie o co chodzi w DDD to prawdopodobnie nic z tego nie wyjdzie. Albo i wyjdzie ale ogromnym kosztem. Na szczęście jest kilka przykładowych projektów w sieci na bazie której możemy czerpać wiedzę i inspirację.

Choć ten przykład w dzisiejszych czasach nie stanowi już aż tak wielkiego problemu to mimo wszystko warto o tym wspomnieć. DDD wymaga pracy w procesie iteracyjnym. Domena jest żywa – dochodzą nowe reguły, inne się zmieniają, zmienia się prawo. To kieruje projekty rozwijane w metodologii DDD do bycia agile.

DDD nie pasuje wszędzie. Techniki te są opłacalne dla projektów operujących na złożonych i nietrywialnych domenach. Nie każdy projekt jest na tyle skomplikowany, że musimy ich używać . Jeżeli mamy prosty proces CRUD’owy z zerową lub marginalną warstwą reguł biznesowych to osadzenie domeny (ciekawe czym ona jest w takim crudzie) tylko niepotrzebnie skomplikuje projekt. Nie po to pojawił się koncept Domain Driven Design.

Podsumowanie

Projektowanie oparte na domenie to podejście inżynierii oprogramowania do rozwiązywania konkretnego modelu domeny. Rozwiązanie krąży wokół modelu biznesowego, łącząc wykonanie z kluczowymi zasadami biznesowymi. W dużych projektach zwykle tylko część modelu (Core Domain) będzie spełniać warunek gdzie DDD powinno być zastosowane. Moim zdaniem jest to jak najbardziej poprawne aby tylko dla części projektu zastosowane było to podejście. Jasne jest, że wpływają na to inne czynniki, np. kompetencje zespołu :).

Źródła:

• Domain Driven Design and Development In Practice
• Domain Driven Design krok po kroku
• What is DDD – Eric Evans – DDD Europe 2019
• WJUG #177 – Domain Driven Design w praktyce – Krzysztof Muchewicz

Za tydzień

Lecimy w świat DDD – omówimy w jaki sposób poznawać domenę.

Artykuł 👉 Domain Driven Design 😱 pochodzi z serwisu bdabek.pl.