„You can do it! Just use AI! Become a Software Generalist”
dwa tygodnie później
Joachim robi to, co my wszyscy
przerabia dwie książki o architekturze i jedną o DDD
ogląda pół konferencji na YouTube, robi notatki
czyta wątki, w których każdy ma inne zdanie
I wyciąga z tego rozsądny wniosek: zanim cokolwiek podzieli, musi zobaczyć, co w ogóle ma. Zaczyna od zebrania ludzi przy ścianie.
Joachim robi Big Picture Event Storming
Świetne na start. Tylko że po warsztacie zostaje ściana karteczek, a nie decyzja.
u Was pewnie też
Prawie każdy zespół ma taki diagram
Kwadraty, beczki, strzałki.
I odpowiada na całkiem sporo pytań
Co widać
co gdzie stoi i na czym jest napisane
co się z czym łączy i przez jaki protokół
gdzie leżą dane i co je czyta
co jest nasze, a co kupione
Czego nie widać
gdzie kończy się odpowiedzialność jednego zespołu
które pojęcie znaczy to samo po obu stronach strzałki
która strzałka jest tania, a która wybuchowa
co wolno zmienić bez pytania nikogo o zgodę
To nie jest wada diagramu. On po prostu opisuje technikę, a nie podział domeny.
i wtedy zaczynają się pytania
Poniedziałek, 9:12, kanał zespołu
# zamowienia
KW
Kasiaproduct owner · 9:12
@Joachim na Black Friday potrzebujemy nowych rabatów. Robimy to my czy Billing? Oba zespoły twierdzą, że to ich.
RN
Robertengineering manager · 9:20
@Joachim Ania wraca z urlopu. Dajemy ją na powiadomienia czy na cennik? Obie rzeczy się palą.
MS
Martabackend · 9:31
@Joachim mała poprawka w zamówieniach, a w release notes znowu płatności, magazyn i raporty. Czemu?
JK
Joachimtech lead
otwiera diagram architektury i pisze
dlaczego Joachim nie umie odpisać
Dwie warstwy tego samego systemu
Obie są potrzebne. Kłopot zaczyna się, gdy od jednej oczekujemy odpowiedzi należących do drugiej.
> whoami
Kamil Kiełbasa
Technical Lead w Jit Team · architekt i konsultant
#programista/architekt#bloger#trener
prawie 15 lat w IT, projekty z różnych branż i różne role
.NET, DDD, Event Storming, systemy rozproszone i chmura
prowadzę szkolenia i warsztaty dla zespołów
współorganizuję Warsaw Software Architecture Group
ponad 7 lat blogowania na bd90.pl, newsletter The Architect’s Edge
żeby odpowiedzieć Kasi, potrzebujemy jednego słowa
Bounded Context
To samo słowo po dwóch stronach granicy znaczy co innego. I bardzo dobrze.
Sprzedaż
Zamówienie
koszyk i pozycje
rabat, cena, promocja
kanał sprzedaży
Magazyn
Zamówienie
lista pozycji do spakowania
waga i gabaryt
adres i status kompletacji
Duże modele rozbija się na osobne konteksty, a potem jawnie opisuje, jak te konteksty się ze sobą mają. Rozbicie robi większość zespołów. Opisanie relacji już nie.
zanim Joachim odpisze na kanale
Czym właściwie jest mapa kontekstów
Eric Evans
Domain-Driven Design, 2003
jawny spis wszystkich modeli, które są w grze, razem z granicami, w jakich obowiązują
punkty styku między nimi i to, co dzieje się z pojęciem, gdy przekracza granicę
opis stanu faktycznego, a nie docelowego
Najpierw narysuj teren taki, jaki jest, łącznie z tym, co Ci się nie podoba. Dopiero mając mapę, podejmujesz decyzje.
Ten sam system, dwa spojrzenia
diagram architektury
mapa kontekstów
Mapy kontekstów nie rysuje się od zera.
Większość tego, czego potrzebujesz, siedzi już w diagramie, który macie na ścianie. Trzeba tylko zadać mu inne pytania.
jak czytać mapę
Relacje na mapie kontekstów
Do tego momentu mapa jest obrazkiem.
Ładnym i pożytecznym przy onboardingu. Tylko że nikt do niej nie zagląda, gdy w piątek trzeba zdecydować, gdzie wyląduje nowe wymaganie.
wracamy do poniedziałkowego kanału
Trzy pytania, cztery warstwy
Sama mapa to wciąż obrazek. Dopiero te warstwy sprawiają, że zaczyna odpowiadać na pytania, które ktoś naprawdę zadaje.
KW
1 · Granica
Gdzie przebiega, kiedy każdy zespół uważa, że dana funkcjonalność należy do niego.
RN
2 · Inwestycja
Gdzie warto wysłać dobry zespół, a co spokojnie można kupić.
MS
3 · Obietnice
Co ten kontekst komuś obiecał i czego nie wolno złamać po cichu.
MS
4 · Stabilność
Dlaczego jedna zmiana pociąga za sobą kolejne konteksty i kolejne wdrożenia.
zanim zaczniecie rysować
Narysowana raz, rozjedzie się z kodem
Każdy refaktor jest lokalnie uzasadniony. Żaden nie wraca do mapy, żeby ją poprawić.
Context Map Evolver
Jeden artefakt, który rośnie razem z tym, ile już wiecie o systemie. Każdy poziom dokładasz dopiero wtedy, gdy masz czym go wypełnić.
L0 · Structure
Konteksty, relacje, kierunek zależności. To wychodzi wprost z diagramu, który macie.
KWRN
L1 · Strategic
Klasyfikacja i pytania. Gdzie granica, gdzie inwestować.
MS
L2 · Promise
Co kontekst komuś obiecał i co ktoś mu narzucił.
MS
L3 · Coupling
Metryki sprzężenia i connascence na krawędziach. Czemu zmiana wysypuje coś obok.
poziom zero
L0 · Structure
map"Classic context map · e-commerce"context ERP { at 150 110 }
context Catalog { at 150 390 }
context Orders { at 800 410 }
Identity -> Orders {
type open-host-service
upstream OHS downstream CF }
ERP -> Catalog {
type customer-supplier
downstream ACL
integration"nightly sync" }
Orders -> Notifications { type conformist }
7 kontekstów, 7 relacji
Tyle da się wyciągnąć z diagramu architektury w jedno popołudnie. I tyle zwykle ludzie nazywają mapą kontekstów.
KWpytanie Kasi
warstwa pierwsza: granica · problem Joachima
„Cena w koszyku inna niż na fakturze?”
pon.
Sales dodaje rabat na Black Friday: druga sztuka 50% taniej. Klient widzi w koszyku 150 zł.
wt.
Billing liczy ten sam rabat po swojemu: od ceny netto, z zaokrągleniem każdej pozycji.
czw.
Klient zapłacił 150 zł, a na fakturze ma 153,75 zł.
pt.
Reklamacja trafia do obu zespołów. Każdy pokazuje, że u niego wszystko się zgadza.
Spór nie jest o kod, tylko o to, czyje jest pojęcie. Rozstrzygają go trzy pytania:
Czyim językiem mówi rabat?Kto płaci, gdy się pomyli?Kto zmienia go najczęściej?
warstwa pierwsza: granica
Pytania główne
Każdy kontekst istnieje po to, żeby odpowiadać na kilka pytań. Jeśli nie umiesz ich wypisać, granica jest w złym miejscu.
Orders
Co klient zamówił?
Czy da się to zrealizować?
Na jakim etapie jest zamówienie?
Payments
Czy klient został obciążony?
Które płatności czekają na rozliczenie?
Co się dzieje przy zwrocie?
Legal
Pod jakimi ograniczeniami działamy?
Kiedy i gdzie wolno użyć licencji?
Kiedy licencja wygasa?
warstwa pierwsza: granica · odpowiedź na mapie
Pytania główne na mapie
Każdy kontekst niesie swoje pytania. Dwa pudełka z tym samym pytaniem od razu rzucają się w oczy.
RNpytanie Roberta
warstwa druga: inwestycja · problem Joachima
„Przecież to tylko kilka ifów”
tydz. 1
Joachim ma dwóch seniorów i trzech juniorów. Seniorów daje na powiadomienia i Kafkę, bo tam jest „najtrudniejsza technologia”.
tydz. 2
Cennik i rabaty trafiają do juniorów. Przecież to tylko kilka ifów.
mies. 3
Powiadomienia mają własny silnik szablonów i trzy poziomy retry. Nikt o to nie prosił.
mies. 4
Biznes chce promocji na Black Friday. Rabaty to 40 zagnieżdżonych ifów, wdrożenie potrwa trzy tygodnie.
Joachim rozdzielił ludzi według trudności technicznej, a nie według tego, na czym firma zarabia.
warstwa druga: inwestycja
Nie każdy kontekst zasługuje na Twój najlepszy zespół
W DDD to są trzy rodzaje subdomen. W mapie zapisujesz je przy kontekście jako jedną etykietę.
Core
Tu jest przewaga konkurencyjna. Buduj sam, najlepszymi ludźmi, i pilnuj tego jak oka w głowie.
Supporting
Potrzebne, ale nikt Was za to nie pokocha. Buduj prosto, bez ceremonii, świadomie taniej.
Generic
Rozwiązany problem. Kup, zintegruj, postaw warstwę tłumaczącą i zapomnij.
Jak to wygląda na mapie
Mapa pokazuje wtedy nie tylko połączenia, ale i to, gdzie idą pieniądze i uwaga zespołu.
warstwa druga: inwestycja
Cynefin, czyli nie każdy kontekst jest tego samego rodzaju
Model Cynefin opracował Dave Snowden pod koniec lat 90. w IBM. Nazwa pochodzi z walijskiego i oznacza mniej więcej siedlisko, czyli miejsce, które nas kształtuje.
Dwie etykiety na kontekście i mapa zaczyna mówić, gdzie wysłać ludzi, a co kupić.
MSpytanie Marty
warstwa trzecia: obietnice · problem Joachima
„Zapłaciłem, a zamówienie anulowane?”
12:00
Klient płaci przelewem przez bramkę płatności. Pieniądze schodzą z konta.
12:15
Orders nie widzi potwierdzenia, więc anuluje zamówienie i zwalnia towar.
12:40
Bank rozlicza przelew. Payments publikuje PaymentConfirmed.
12:41
Klient ma pusty portfel, anulowane zamówienie i dzwoni na infolinię.
Orders zakładał, że potwierdzenie przychodzi w kilka minut. Payments nigdy tego nie obiecał, bo nie ma wpływu na to, kiedy bank rozliczy przelew.
warstwa trzecia: obietnice
Promise Theory
Model współpracy autonomicznych agentów, opisany przez Marka Burgessa. Agenci nie wydają sobie poleceń, tylko składają dobrowolne obietnice.
Agent kontroluje wyłącznie własne zachowanie. Bounded Context jest dokładnie takim agentem.
Obietnica ma sens dopiero wtedy, gdy ktoś z zewnątrz jest w stanie sprawdzić, czy została dotrzymana. Stąd obserwator na rysunku.
Obietnica kontra narzucenie
Promise
„Będę publikował zdarzenie o przyznaniu licencji w ciągu minuty.”
Składa ją ten, kto ma nad tym kontrolę. Da się ją zweryfikować i da się jej zaufać.
Imposition
„Macie publikować to zdarzenie w ciągu minuty.”
Narzucone z zewnątrz, bez kontroli nad wykonaniem. Wygląda jak ustalenie, a jest życzeniem.
Anatomia obietnicy
Obietnica ma autora, odbiorcę, treść i warunki. Jeśli któregoś z tych czterech brakuje, to nie jest obietnica, tylko założenie.
Mapa jako zbiór obietnic
warstwa trzecia · odpowiedź na mapie
L2 · Promise Theory
context Orders {
promise + "an accepted order is valid and paid"to Warehouse
promise - "payment confirmation"from Payments
if"order total is positive"
}
context Carrier {
// to nie jest obietnicaimposition"you must use our label format"on Warehouse
}
Plus to obietnica złożona, minus to obietnica, na której polegasz. Narzucenie rysuje się inaczej, bo nim nie jest.
MSpytanie Marty
warstwa czwarta: stabilność · problem Joachima
„To co, wdrażamy dziś płatności?”
JK
Joachim
To co, wdrażamy dziś poprawkę w płatnościach?
MW
Marekbackend
Jak płatności, to magazyn też musi iść. Zmienił się format eventu.
PZ
Piotrdane
A jak magazyn, to raportowanie też. Inaczej rano dashboardy pokażą zera.
MS
Martabackend
Panowie, coś nam chyba nie wyszło to event driven.
warstwa czwarta: stabilność
Coupling
Sprzężenie to klej, który trzyma system w całości.
parafraza, Vlad Khononov
Bez sprzężenia zegarek nie chodzi. Koła muszą się zazębiać, inaczej nic nie napędza niczego.
Ale im ciaśniej je dociśniesz, tym szybciej zetrą się zęby i tym trudniej wymienić jedno koło bez rozbierania całego mechanizmu.
Connascence
Miara jakości mówiąca, kiedy dwa elementy muszą zmieniać się razem, żeby system pozostał poprawny.
pojęcie spopularyzowane przez Meilira Page-Jonesa, 1992
Sprzężenie mówi, że coś jest połączone. Connascence mówi, jak bardzo boli, gdy to ruszysz.
Connascence ma trzy wymiary
Siła
Jak trudno to wykryć i bezpiecznie zmienić. Od nazwy, przez typ i pozycję, po wykonanie i czas.
Lokalność
Jak daleko od siebie leżą powiązane elementy. To samo powiązanie w jednej klasie jest nieszkodliwe, a między kontekstami bywa zabójcze.
Stopień
Ile miejsc trzeba ruszyć naraz. Dwa wywołania to drobiazg, czterdzieści to projekt.
Reguła praktyczna: im dalej od siebie, tym słabsza connascence powinna je łączyć.
warstwa czwarta: stabilność
Ca, Ce i niestabilność
Ca, afferent coupling — ile kontekstów zależy od Ciebie. Trzy strzałki wchodzące.
Ce, efferent coupling — od ilu kontekstów zależysz Ty. Jedna strzałka wychodząca.
I, niestabilność — I = Ce / (Ca + Ce). Zero znaczy, że wszyscy na Tobie wiszą i nie możesz się ruszyć. Jeden znaczy, że nikt Cię nie potrzebuje i zmieniasz się bez konsekwencji.
Metryki Roberta C. Martina, opisane w OO Design Quality Metrics z 1994 roku, a potem w Agile Software Development i Clean Architecture. Powstały dla pakietów w kodzie. Na mapie kontekstów działają tak samo.
Co to daje na mapie kontekstów
Strzałka przestaje być jedna. Zaczynasz widzieć, co dokładnie przez nią przechodzi i co pęknie przy zmianie.
warstwa czwarta · odpowiedź na mapie
L3 · Coupling & Connascence
Legal -> Availability {
type customer-supplier
upstream OHS
downstream ACL
integration"DNS + PL"coupling 2
connascence meaning distant 3
}
Ca, Ce i niestabilność liczone na każdym kontekście
krawędzie ważone rodzajem connascence, Co→Value 83 kontra Co→Name 24
kolor mówi, gdzie pęknie najpierw
piątek, 16:40
I wtedy przychodzi nowe wymaganie
Joachim ma teraz mapę. Wraca na kanał, na którym od poniedziałku czekają trzy pytania. A Kasia właśnie dopisała czwarte.
ten sam kanał, cztery dni później
Piątek, 16:41, kanał zespołu
# zamowienia
JK
Joachimtech lead · 16:41
@Kasia rabaty liczymy my. To język koszyka i to my płacimy za pomyłkę w cenie. Billing dostaje gotową kwotę.
JK
Joachimtech lead · 16:42
@Robert Ania idzie na cennik. To core, tam firma zarabia. Powiadomienia wystarczy kupić.
JK
Joachimtech lead · 16:43
@Marta Orders czeka na przelew tyle, ile obiecał Payments, a nie 15 minut. A magazyn dostaje od nas opublikowany format, więc płatności wdrażamy osobno.
KW
Kasiaproduct owner · 16:44
@Joachim super. A program lojalnościowy dorzucimy do zamówień? Biznes chce na poniedziałek.
JK
Joachimtech lead · 16:45
Nie tutaj. Loyalty to osobny kontekst. Orders nie będzie obiecywał punktów, nad którymi nie ma kontroli.
Context Map przestaje być dokumentacją, gdy zaczyna zmieniać decyzje.
Dopóki tylko opisuje stan zastany, jest kosztem. Od momentu, w którym pomaga powiedzieć „nie tutaj”, jest narzędziem.
do zabrania z sali
Od czego zacząć w poniedziałek
Trzy kroki na diagramie, który już macie. Godzina pracy i macie pierwszą mapę, która na coś odpowiada.
1
Pytania przy pudełkach
Przy każdym pudełku wypiszcie trzy pytania, na które odpowiada. Dwa pudełka z tym samym pytaniem to kandydaci na złą granicę.
2
Jedna etykieta
Dopiszcie core, supporting albo generic. Porównajcie z tym, gdzie dziś siedzą Wasi najlepsi ludzie.
3
Obietnica przy strzałce
Przy każdej strzałce zapiszcie, co jedna strona obiecuje drugiej i na jakich warunkach. Strzałka bez obietnicy to założenie.
Connascence zostawcie na drugi tydzień. Najpierw niech mapa odpowie na te trzy rzeczy.
źródła
Do poczytania
podstawy: Bounded Context i Context Map
Domain-Driven Design
Tackling Complexity in the Heart of Software
Eric Evans
Addison-Wesley, 2003
warstwa 2: inwestycja
Learning Domain-Driven Design
Aligning Software Architecture and Business Strategy
Vlad Khononov
O’Reilly, 2021
warstwa 3: obietnice
Thinking in Promises
Designing Systems for Cooperation
Mark Burgess
O’Reilly, 2015
warstwa 4: stabilność
Balancing Coupling in Software Design
Universal Design Principles for Architecting Modular Software Systems
