// wszystkie materiały zostały zebrane w podsumowaniu cyklu.
Podział naszego rozwiązania na mniejsze konteksty to temat, który zwykle pojawia się podczas tworzenia bardziej rozbudowanego systemu. Szczególnie jeśli mówimy o mikroserwisach. Dlaczego tak jest?
Nieprawidłowy podział systemu niesie ze sobą szczególne wady:
- praca będzie przechodziła przez wiele obszarów technicznych
- rozwój funkcji biznesowy wymagać będzie koordynacji pracy kilku zespołów
- wiedza o statusie procesu będzie podzielona na kilka miejsc - brak będzie jednego źródła prawdy
- rozwój jednej funkcji biznesowej będzie burzyć działanie funkcji pobocznych
Na potrzeby tego artykułu wyszczególniłem 5 metod dzielenia systemu na konteksty:
Metody podziału na konteksty
Proces i jego podział
Ta metoda podziału jest najbardziej popularna (co też oznacza, że nie zawsze właściwa).
Rozpoczynamy od przeglądu naszego procesu, który chcemy informatyzować (u mnie oczywiście za pomocą Event Stormingu 😉). Zbieramy informacje w jaki sposób przebiegają kolejne kroki. Wyszczególniamy kto się z kim komunikuje, oraz jakie informacje podaje dalej. A przede wszystkim, jakie cele chcemy spełniać na poszczególnych etapach procesu.
Następnie szukamy zdarzeń granicznych (pivotal events). To pozwoli nam określić w których miejscach proces zauważalnie zmienia swoją strukturę - pracują w nim inne osoby lub proces spełnia inne cele. W systemie e-commerce takimi zdarzeniami mogą być:
- Zlecono wysyłkę - dział Zamówień oddał pracę dalej do działu Dostaw
- Uruchomiono kampanię marketingową - teraz dział Marketingu skupi się na zbieraniu leadów
- Wyłączono produkt ze sprzedaży - sprzedaż produktu nie jest już możliwa
Bardzo często miejsce podziału procesu będzie pokrywało się z obecną strukturą organizacyjną, bądź z strumieniem wartości (value stream). W ten sposób odkryjemy główny podział procesu i mniejsze obszary biznesowe.
Na tej podstawie możemy utworzyć nasze konteksty. Aktywności biznesowe danej grupy docelowej oraz przetwarzane informacje będą zawierać się w danym obszarze biznesowym. Zamykamy część procesu biznesowego tworząc dla niego osobny kontekst.
Zadaj sobie pytanie:
- W którym miejscu mój proces się dzieli?
- Gdzie oddajemy pracę innej osobie / innemu działowi?
- Jakie informacje są wymagane od działu w którym współpracuję?
Możliwości zmiany i autonomia
Jeśli widzimy, że pewne funkcje i cele biznesowe są często zmieniane, jest to dla nas sugestia, że warto dla nich wydzielić osobny kontekst. Nawiązuje to do słynnej pracy D.L. Parnasa On the Criteria To Be Used in Decomposing Systems into Modules
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
Załóżmy, że nasz dział marketingu wykorzystuje promocje w systemie e-commerce. Istnieją różne rodzaje promocji, a wobec czego różne sposoby liczenia cen produktów. Część z tych promocji może się na siebie nakladać, część nie. Ostatecznie skończymy z olbrzymim narzutem promocji na implementację funkcji zakupów. Wyliczenie ostatecznej ceny produktu będzie skomplikowane, czasochłonne i zaburzało proces zakupów.
Dlatego też wartościowe będzie odseparowanie od siebie tych odpowiedzialności. Liczenie cen przeniesiemy do kontekstu Cennik, który będzie odpowiedzialny za bazowe ceny produktów oraz promocje. Tutaj będzie wyliczana ostateczna cena produktów. Na tej podstawie zasilony zostanie kontekst Sklep, który dostanie gotowe informacje do działania. Cennik może dowolnie kształtować i zmieniać promocje, o ile dalej będzie zapełniać Sklep danymi.
Przydatną techniką tutaj jest Mapa Wardley’a. Pozwala ona, po podziale na obszary, zastanowić się na ile są one dojrzałe i stabilne. Na tej podstawie możemy podjąć powyższe decyzje.
Zadaj sobie pytanie:
- Jakie potrzeby biznesowe się częściej zmieniają?
- Co jest na tyle stałe, że nie zmienialiśmy tego od miesięcy?
- Gdzie najczęściej wpadają zmiany na już, ASAP as ASAP?
Źródło wiedzy
Ta metoda podziału pozwala nam skupić się na bardziej ukrytych kontekstach. Są to również te konteksty, których podskórnie poszukują nasi klienci.
Załóżmy, że tworzymy rozbudowany system e-commerce. Możemy sprzedawać / rezerwować / zamieniać reklamacyjnie produkty. Każda z tych akcji blokuje konkretne sztuki produktów. Zadaj sobie wtedy pytanie “Ile mam danego produktu możliwego do sprzedaży?" Odpowiedź na to pytanie nie będzie łatwa - wymagane będzie przeliczenie 3 zbiorów danych.
To jest sugestia, że brakuje nam dodatkowego obszaru, który będzie się zajmować obsługą dostępności produktów. Taki kontekst będzie przyjmował żądania blokowania produktu i zwracał podsumowanie dostępności. Kontekst Dostępność będzie tutaj źródłem wiedzy. To do niego pozostałe konteksty będą uderzać aby pytać o dostępność produktów i blokować poszczególne towary.
Często różne grupy mówią o tej samej funkcji z różnej perpektywy. Źródło wiedzy jest sposobem by zebrać te potrzeby w jednym miejscu i nadać im techniczny kształt.
Zadaj sobie pytanie:
- Na jakie główne pytania powiniśmy odpowiedzieć w naszym systemie?
- Co jest dla nas najbardziej istotną informacją w systemie?
- Jaka odpowiedź powinna być dla nas znana bez zapytań do innych kontekstów?
Różnice językowe
Słowa mają różne znaczenia, w zależności od obszaru biznesowego. Kontekst (w ujęciu DDD) dzieli rozwiązanie techniczne na mniejsze obszary, gdzie wybrane pojęcie ma dokładnie jedno znaczenie.
Weźmy na tapet słowo Lead. W zalezności czy mówimy o zespole Marketingu czy Sprzedaży to słowo Lead będzie znaczyło coś zdecydowanie innego (przykład dyskusji z LinkedIn). Taką istotną różnicę warto odseparować od siebie - inaczej skończymy z olbrzymim modelem mającym bardzo dużą odpowiedzialność.
Analogicznie może być w przypadku słowa Pracownik w systemie HRowym. W zależności od kontekstu te słowa mogą znaczyć:
- Szansa na zatrudnienie - dla kontekstu Poszukiwanie kandydatów
- Potencjalne miejsce angażu - dla kontekstu Projekty
- Miejce w drabince organizacyjnej - dla kontekstu Struktura organizacyjna
- Stawka godzinowa oraz dni urlopowe - dla konktestu Koszty
Zadaj sobie pytanie:
- Jakie zwroty są różnie rozumiane w mojej organizacji?
- O jakie odpowiedzialności / cechy / zachowania kłócą się współpracownicy?
- Jakie pojęcia są strasznie niejasne (a więc ich klasy / obiekty w kodzie olbrzymie)?
Reużywalność
Jednym ze sposobów na wydzielenie kontekstów jest myślenie w kryteriach reużywalności.
Płatności są tego dobrym przykładem. Na początku chcielibyśmy aby klienci mogli nam płacić za towary. Połączenie odpowiedzialności płatności z zamówieniem wydają się dobrą decyzją na start. Później jednak możemy chcieć aby klient mógł zapłacić dodatkową kwotę za rzeczy niezwiązane z zamówieniem - dodatkową wysyłkę, wymianę. Dodanie nowych funkcji do już istniejących płatności w zamówieniach może przyprawić o siwe włosy.
Wydzielenie reużywalnego kontekstu Płatności daje nam duże zyski w tworzeniu bardziej modularnego systemu. Pozostałe konteksty mogą prosić Płatności o realizację płatności, bez informowania kontekstu dlaczego się to dzieje. Możemy łączyć ze sobą konteksty na zasadzie klocków, tworząc nowe procesy.
Zadaj sobie pytanie:
- Jakie funkcje mogą być wykorzystywane przez różne części biznesu?
- Jaka odpowiedzialność powtarza się w procesach biznesowych?
- Co się pokrywa w dyskusjach poszczególnych grup / departamentów organizacji?
Podsumowanie i materiały
Bounded Contexts shouldn’t serve the designer’s sensibilities and need for perfection, but enable business opportunities.
Wydzielanie kontekstów to zadanie, które jest zarówno techniczne, jak i biznesowe. Nie przeprowadzamy podziału by chwalić sie najlepszym technicznie podziałem. Jednak dobrze wydzielone konteksty przyśpieszają pracę i pozwalają na rozwijanie nowych możliwości biznesowych. I tego wam życzę.
W internecie możecie poczytać więcej o metodach dzielenia na konteksty - daj znać w komentarzach jakie Ty stosujesz podejścia 😀
