Event storming - proces
Przygotowanie (przed event stormingiem)
Co jest w tej firmie core domain? Jaki jest wyróżnik biznesowy? Co trzeba zbudować.
Co jest domenami wspierającymi? Czyli tymi, które trzeba zrobić, ale nie są kluczowe.
Co jest domenami generycznymi? Co możemy kupić z zewnątrz?
Kogo zaprosić?
Spotkanie prowadzi facilitator.
Ekspertów domenowych
Stake Holderów
Modelarza
Programistów
Odkrywanie domen
Struktura organizacji
Które domeny są ze sobą połączone i w jaki sposób?
Patrzenie na ekspertów domenowych
Np. gdy obsługa klienta lokalnego jest inna niż zagranicznego
Język domenowy ekspertów
Co oni mówią i jak oni mówią?
Unikać duplikatów w języku - jeśli jest to coś innego, to należy to zawsze zaznaczyć. Utrzymywać definicję (nawet słowniczek).
Wartość biznesowa
Core domain, czy tylko jedna, czy jest ich więcej?
Kroki procesu biznesowego
Jak zmienia się proces biznesowy w czasie?
Jak z czasem zmieniają się Domeny i Subdomeny
Przygotowanie big picture event storming
Przestrzeń - duża ściana
Ściana
Karteczki
Flamastry
Flipchart
Minutnik
Faza 0: Rozpoczęcie spotkania
Przedstawienie celu spotkania
Faza 1: Chaotyczna eksploracja
Event - pomarańczowa karteczka
Wyłącznie istotne zdarzenia z punktu widzenie systemu, ale jednocześnie każda karteczka jest ważna, bo może otwierać dyskusję do elementu który normalnie byłby pominięty.
Każdy uczestnik ma za zadanie napisać jakieś istotne zdarzenie i przykleić je na ścianę
Zdarzenia w czasie przeszłym np. "Zamówienie zostało opłacone"
Każdy pracuje osobo, by wyeliminować samca alfa
Zakończenie gdy pierwsza osoba skończy
Faza 2: Wprowadzenie osi czasu
Wprowadzenie struktury
Usunięcie duplikatów
Pojawienie się niejasności
Faza 3: Opowieść od końca
Walidacja, czy to się udało?
Jakich wydarzeń brakuje?
Cognitive workload
Faza 4: Ludzie i systemy
Np. używamy dropboxa
Np. Pan Mietek odpowiada za wysyłkę
Systemem może być dział firmy
Nie każdy event ma swojego aktora
Faza 5: Problemy i okazje
Zaznaczanie ważnych problemów czerwoną karteczką
Definicja metryk biznesowych
Process level event storming
Połączenie event stormingu w określone procesy
Na takim wydarzeniu może być już znacznie mniej osób, ale napewno powinni być ownerzy poszczególnych procesów, którzy ostatecznie decydują o kształcie aplikacji.
Analiza części pierwszych polegająca a rozbiciu poszczególnych evetów na eventy z kontekstem.
Kolejność
Actor (żółta karteczka) - kupujący klient
Command (niebieska karteczka) - dodaj produkt do koszyka
System (różowa karteczka) - produkt musi być dostępny na stanie; ilość dodanych do koszyka produktów nie przekracza maksymalnej ilości zamówień na jedną osobę;
Event (pomarańczowa karteczka z Big Picture Event Storming) - produkt został dodany do koszyka
Policy (łososiowa karteczka) - zmniejsz stan dostępności o ilość produktów dodanych do koszyka
Widok (zielona karteczka) - wyświetl zamówienie w koszyku
Następnie dodanie do nich bounded contextów.
Pozwala wydzielić moduły w aplikacji - warto o nich myśleć jak osobnych, niezależnych od siebie elementów. Niezależnie od tego czy jest to montolit czy mikroserwisy, lepiej nawet działać w zakresie modułowego monolitu.
7 taktyk porozumienia
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Conformist - minimalizacja kosztów migracji np. integracja z FB z dużym couplingiem
Customer-supplier
jeden dostarcza, inny odbiera np. klient chce kupić od dostawcy
Indywidualne kontrakty dla każdego klienta
Open host
Customer-supplier, ale customerów są miliony
Jeden wspólny kontrakt dla wszystkich
Published language
Kontrakt jest delegowany na 3 stronę
Częste wersjonowania API (po nagłówkach http - Accept)
Shared Kernel
Powszechne użycie przez wszystkich
Ownerem są wszyscy
np. sposób kodowania danych
Anti Corruption Layer
Przeciwieństwo shared kernela
Separate ways
Walidacja
Czy bounded ccontexty są
Czy wszystkie eventy faktycznie są potrzebne w systemie? Jaka jest ich rola? Czy należą do określonego bounded contextu?
Last updated
Was this helpful?