Przejd┼║ do tre┼Ťci

Bounded context w DDD ­čĹÇ

Technika Bounded Context jest najbardziej wyrafinowan─ů i subteln─ů z technik DDD. Zak┼éada ona istnienie r├│┼╝nych modeli opisuj─ůcych te same byty, u┼╝ywanych w r├│┼╝nych kontekstach.


Cze┼Ť─ç┬á­čÖé

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

W dzisiejszym artykule:


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:


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.

4.7 7 votes
Article Rating
Subscribe
Powiadom o
guest
1 Komentarz
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
Marcin
Marcin
2 lat temu

Dzi─Öki za artyku┼é. Pragmatyczna esencja odno┼Ťnie kilku kwestii dekompozycji. Szkoda, ┼╝e nie ma dalszej cze┼Ť─çi i pokazania bardziej skomplikowanego przypadku, kiedy BC nie jest 1:1 z subdomen─ů

1
0
Would love your thoughts, please comment.x