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 MSi 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:

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.

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 1 vote
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments