Notes

[MateuszNaKodach]

Rozszerzona mapa kontekstów. Granice IT i biznesu sie przenikaja, dlatego solution space i problem space - podzial nie wniesie wiele.

[MateuszNaKodach]

Cykl Kolba

[MateuszNaKodach]

Stażu nie mylic z doswiadczeniem.

Poziom trudności szkolenia narasta zgodnie z modelem Braci Dreyfus, czyli modelem rozwoju jednej, konkretnej kompetencji. Na początku jesteśmy nowicjuszem i potrzebujemy konkretnych kroków: Co mam zrobić i jak mam zrobić? Na drugim poziomie, czyli zaawansowany początkujący, nadal jesteśmy nastawieni na zadania, ale już sami potrafimy składać sobie kroki. Mamy tendencję do zawyżania kompetencji i nie potrafimy się sami korygować, czyli jesteśmy niebezpieczni dla siebie i otoczenia. Na poziomie kompetentnym jesteśmy już nastawieni na cel, zaczynamy dostrzegać powtarzalne wzorce, ale mamy jeden młotek do wszystkiego. Aby pójść dalej, potrzeba włożenia ogromnego wysiłku poznawczego i lat doświadczeń. Nowych doświadczeń, a nie repetycji, bo powtarzanie tego samego przez kolejne lata nic nie zmieni. Tak jak jeżdżenie z domu do pracy samochodem przez 20 lat nie pomoże w żaden sposób podczas startu w wyścigach, a raczej tylko zaszkodzi.

[MateuszNaKodach]

Jakie bylyby konsekwencje nie spelnienia reguly? Pytac biznesu w przypadku lockingu / concurrency / granic spojnosci.

Process Aggregate - building block.

[MateuszNaKodach]

Według nas dobry projekt techniczny to taki, który pozwala łatwo zmienić zdanie co do wcześniej podjętych decyzji. Zakładamy, że będziemy musieli zmieniać granice modeli i to decyzje podjęte właśnie na tym etapie sprawią, czy będzie to kosmetyczna zmiana, czy wielomiesięczna przebudowa stajni Augiasza. Będziesz uczyć się usuwania couplingu pomiędzy elementami konstrukcyjnymi. Pewne jest to, że reguły procesowe i domenowe będą zmieniać się niezależnie od siebie Jeśli dobrze wybierzesz styl architektury aplikacyjnej, to nie odczujesz tych zmian drastycznie.

Twój model albo umożliwia szybkie pivoty, albo nie. Twój model albo oferuje możliwość nieplanowanej produktyzacji modułów, albo nie. Wszystko płynie i po kilku latach twoje core'owe moduły stają się tzw. Commodity. Nawet konkurencja już robi to dobrze. I teraz to nowe obszary stają się core’owe.

[MateuszNaKodach]

Moduly

Dekompozycja nie jest celem, tylko narzedziem do walki ze zlozonoscia. Ciezki do zrozumienia i ciezki do zmiany. Czasem jej nie ma. Modularyzacja to inwestycja, po czasie zobaczy sie zysk. Praca ze zle podzielonym systemem jest ciezsza niz w ogole nie podzielonym.

Programiście albo programistce, modularyzacja pozwala skupić się na wycinku złożoności, dzięki czemu zmniejsza się przeładowanie kognitywne, zmniejsza się potrzeba integracji i czekania na wynik prac innych zespołów, a do głowy przychodzą po prostu lepsze pomysły - takie, z których potem można się łatwiej wycofać, bo zmiana będzie lokalna. Product Ownerowi modularyzacja daje jasny podział odpowiedzialności. W końcu wie on lub ona, do jakich zespołów musi pójść w celu implementacji nowego pomysłu. Zespoły też czują sprawczość. Analitykowi czy też analityczce dobra modularyzacja daje narzędzie walidacji pomysłów biznesowych bez angażowania zespołu programistycznego, czyli dużo szybciej. Dla sponsora projektu modularyzacja to technika oszczędzająca pieniądze, szczególnie w strategicznych systemach o długim cyklu życia.

Na etapie poznawania złożoności biznesu nie wiemy jeszcze jakimi wzorcami i jaką architekturą aplikacyjną będziemy implementować poszczególne moduły biznesowe. Nie jest to jeszcze istotne, o ile poznaliśmy dobrze ich granice, ale już teraz warto zaznaczyć, że moduł symbolizuje wektor zmiany w systemie. Czyli moduł techniczny przygotowuje system na zmianę techniczną. Np. zmiana bazy danych odbędzie się teraz w jednym module, ale zmiana biznesowa, która skutkuje dodaniem pola do modelu, w takim podziale technicznym skutkuje zmianą kilku modułów. Z naszego doświadczenia zmiany wymagań funkcjonalnych są częstsze niż te z powodów niefunkcjonalnych, ale oczywiście nie jest to sztywną regułą. Podział zawsze powinien po prostu minimalizować miejsca do zmiany.

[MateuszNaKodach]

Nadmiernie wyspecjalizowane modele.

Tutaj z pomocą przychodzi pewna sztuczka. Słuchając wymagań, gdzie występują 2, 3 albo i 10 zmiennych reguł i wiele z nich pochodzi od różnych interesariuszy, załóż roboczo, że każda z tych reguł to przypadek specyficzny. Nawet jeśli to jest na razie jedyny przypadek. Postaraj się zamodelować rozwiązanie tak, żeby obsługiwać każdy przypadek specyficzny, bez uwidaczniania od razu tego przypadku w kodzie, czyli żeby jakaś ogólna reguła rozwiązywała każdy przypadek specyficzny. I to nazywamy uogólnianiem poprzez usuwanie przypadków szczególnych. A to, co powstaje po takiej technice, to model ogólnego przeznaczenia. Albo też model głębok

Ktos bedzie dodawal siedliska, ktos artefakty robi. To tak jak z notyfikacjami np. Jakiej ogólnej reguły przedstawicielami są pojawiające się poszczególne przypadki? Czy w ogóle taka istnieje, bo może jej nie znajdziesz?

Goniec, gra w szachy

[MateuszNaKodach]

[MateuszNaKodach]

W glowie usera jest logika, np Grafana jest takim systemem.

[MateuszNaKodach]

[MateuszNaKodach]

[MateuszNaKodach]

Jak pewnie się już orientujesz, śledząc losy naszych bohaterów, będziemy porównywać ze sobą trzy podejścia do projektowania systemu. Pierwsze będzie dość naiwne, bazujące na bardzo prostych technikach, które są świetne, ale tylko do bardzo prostych problemów, których nie brakuje w dużym systemie. Podejście to powstało na przełomie tysiąclecia, na potrzeby bańki internetowej dot-com, kiedy zaczęły powstawać pierwsze fabryki oprogramowania w Indiach. Zatrudniano w nich na szybko pobieżnie przeszkolonych pracowników. Serwis i anemiczna encja to elementy konstrukcyjne przygotowane pod ten profil pracownika. Przedstawicielem tej szkoły jest nasz kolega w kamizelce - Marian. Drugie podejście będzie reprezentowane przez entuzjastycznie nastawionego do wszystkiego co nowe, neofity Domain-Driven Design - Brajana. Jak widzisz, pobieżna znajomość technik oraz brak doświadczenia w doborze klasy narzędzia do klasy problemu, skutkuje sporymi problemami, zarówno na poziomie technicznym, jak i na poziomie kultury pracy oraz współpracy z tzw. biznesem. To normalny etap w rozwoju każdej kompetencji, ale chcemy ci pomóc przez ten etap przejść.

Trzecie podejście, nazwijmy je klasycznym, ponieważ wyłoniło się w latach 70., a ugruntowało w latach 80., jest reprezentowane przez tytułowych Domain Drivers. Chcemy pokazać ci stonowane i zdystansowane podejście do wszystkich narzędzi i technik. Nadrzędna zasada Driversów to rozpoznać klasę problemu i dobrać do niej klasę rozwiązania, biorąc pod uwagę drivery biznesowe i techniczne. Ich celem nie jest zastosowanie DDD czy event stormingu, tylko nastawienie na rozpoznanie celów biznesowych i dostarczanie rozwiązania o jakości odpowiedniej do założonego celu strategicznego. Postaci Driversów zdradzą ci sposób myślenia konsultanta zmierzającego do wspólnego dobra, prawdy i piękna.

[MateuszNaKodach]

Pierwsze zetknięcie z DDD, szczególnie na poziomie strategicznym, to często poczucie konfuzji wynikające z natłoku pojęć. Problem Space, Solution Space, Domena, Sub-domena, Bounded Context, Moduł. Weź pod uwagę kontekst historyczny. Pierwsza książka na temat DDD była pisana na początku wieku. Organizacje, które tworzyły wówczas duże systemy były w trakcie informatyzowania się. W tamtych czasach było wyraźnie widać różnicę pomiędzy przestrzenią problemu, a przestrzenią rozwiązania. Musieliśmy mapować na siebie to, jak jest zorganizowany biznes, czyli domeny i poddomeny, na to, jak organizujemy modele, czyli Bounded Contexts. Z premedytacją nie definiujemy teraz tych pojęć, bo nie ma to aż takiego znaczenia dzisiaj, kiedy w większości organizacji IT oraz biznes się przenikają, a granice pomiędzy nimi się zacierają. W większości przypadków, szczególnie w małych systemach, ten podział nic nie wniesie.

[MateuszNaKodach]

Cykl Kolba

Docelowo chcemy, abyś mógł/mogła uczyć DDD w swojej organizacji, bazując na głębokim zrozumieniu, dlaczego i po co coś robisz. Każdy moduł szkolenia jest oparty o cykl Kolba. Zaczniemy od doświadczenia problemu.Następnie naprowadzimy cię na obserwacje i wnioski, po to aby wspólnie lub dyrektywnie dojść do teorii, którą następnie wypróbujesz w praktyce, aby problem rozwiązać lub przesunąć się o jeden cykl bliżej tego rozwiązania. Poziom trudności szkolenia narasta zgodnie z modelem Braci Dreyfus, czyli modelem rozwoju jednej, konkretnej kompetencji. Na początku jesteśmy nowicjuszem i potrzebujemy konkretnych kroków: Co mam zrobić i jak mam zrobić

Na drugim poziomie, czyli zaawansowany początkujący, nadal jesteśmy nastawieni na zadania, ale już sami potrafimy składać sobie kroki. Mamy tendencję do zawyżania kompetencji i nie potrafimy się sami korygować, czyli jesteśmy niebezpieczni dla siebie i otoczenia. Na poziomie kompetentnym jesteśmy już nastawieni na cel, zaczynamy dostrzegać powtarzalne wzorce, ale mamy jeden młotek do wszystkiego. Aby pójść dalej, potrzeba włożenia ogromnego wysiłku poznawczego i lat doświadczeń. Nowych doświadczeń, a nie repetycji, bo powtarzanie tego samego przez kolejne lata nic nie zmieni. Tak jak jeżdżenie z domu do pracy samochodem przez 20 lat nie pomoże w żaden sposób podczas startu w wyścigach, a raczej tylko zaszkodzi

[MateuszNaKodach]

L04. Jak korzystać z tego szkolenia. [36:55]

Zakładamy, że będziemy musieli zmieniać granice modeli i to decyzje podjęte właśnie na tym etapie sprawią, czy będzie to kosmetyczna zmiana, czy wielomiesięczna przebudowa stajni Augiasza. Będziesz uczyć się usuwania couplingu pomiędzy elementami konstrukcyjnymi. Pewne jest to, że reguły procesowe i domenowe będą zmieniać się niezależnie od siebie Jeśli dobrze wybierzesz styl architektury aplikacyjnej, to nie odczujesz tych zmian drastycznie. Na koniec zobaczysz jak nisko- i średnio-poziomowe decyzje mogą wpływać na strategiczny kierunek biznesu. Twój model albo umożliwia szybkie pivoty, albo nie. Twój model albo oferuje możliwość nieplanowanej produktyzacji modułów, albo nie. Wszystko płynie i po kilku latach twoje core'owe moduły stają się tzw. Commodity. Nawet konkurencja już robi to dobrze. I teraz to nowe obszary stają się core’owe. Będzie dużo kodu w kilku technologiach.

[MateuszNaKodach]

Każdy, kto próbował stworzyć jeden wielki model, taki składający się z setek czy też z tysięcy tabel, poległ. A jeśli twierdzi inaczej, to zapytaj jego lub jej programistów i programistek. Według nas najważniejszą umiejętnością w programowaniu jest dekompozycja problemu na mniejsze problemy, aby móc rozwiązać każdy z tych problemów relatywnie tanio oraz aby móc osobno zmieścić je w głowie bez przeładowania kognitywnego. Dlatego też w Domain-Driven Design tworzymy modele, które służą do rozwiązywania konkretnego problemu oraz pozwalają zadać konkretne pytania. Modele te ograniczone są do tzw. kontekstu, w jakim mają sens - kontekstu, na którego potrzeby zostały stworzone. W większym systemie istnieje wiele modeli, które łączą się ze sobą. Musimy jakoś zbudować kompletne rozwiązanie. Małe modele są łatwiejsze do zrozumienia, ale pojawia się inny problem - relacja pomiędzy modelami. Z tej relacji wynika relacja pomiędzy modułami, czy też mikroserwisami, jeśli ich potrzebujesz. Z tego natomiast wynikają zależności pomiędzy zespołami.

[MateuszNaKodach]

Pamiętaj: facylitator jest jak partner w sztukach walki, a nie twój przeciwnik. On cię przewraca, abyś nauczyła czy nauczył się wstawać, a później już stać stabilnie.

[MateuszNaKodach]

[MateuszNaKodach]

Chcemy jednak, żebyś zaczął/zaczęła myśleć również w drugą stronę. W pewnym kontekście kilka różnych rzeczy jest tym samym, np. w kontekście dostępności zarówno ludzie, jak i maszyny oraz pomieszczenia i materiały będą dla nas tym samym. Po prostu będą zasobem. Być może w trakcie sesji modelowania takie słowo jak zasób nie padnie, ponieważ będziemy spotykać się z ludźmi z obszarów biznesu zajmujących się maszynami i pomieszczeniami.

[MateuszNaKodach]

Pamiętaj, chodzi o podział na logiczne podproblemy biznesowe, na logiczne modele odpowiadające za różne problemy, a nie na techniczne warstwy czy jednostki wdrożeniowe w postaci mikroserwisów

[MateuszNaKodach]

L01. Rozwiązanie: Przykład deep modelu - harmonogramu. Jak na nie wpadać? [15:56]

To oczywiście diabelski trik na to, żeby zachęcić do zakupu najdroższej konfiguracji. Wizualizując to, jest szansa, że zobaczysz jakąś strukturę. Tą strukturą jest drzewo. Często w proces modelowania wkracza właśnie taki niespodziewany błysk intuicji, a ktoś z boku ma wrażenie wyjmowania królika z kapelusza. Ta do końca jeszcze niewyjaśniona zagadka intuicji jest najpewniej nieuświadomioną wiedzą, która pochodzi z doświadczenia. I trzeba jawnie przyznać, że intuicja sprzyja tym, którzy mieli okazję eksponować się na różne przypadki. Rozwiązanie wtedy jest zaskakującym skojarzeniem dwóch tak odległych dziedzin, że logiczny tok myślenia nie zawsze je łączy. Czyli im więcej przypadków widzisz, tym lepiej modelujesz. Ale uwaga, nie musisz zmieniać pracy, żeby te przypadki widzieć, obserwować i eksponować się na nie. Zwróć uwagę np. na konfigurację MacBooka. Wystarczy po prostu obserwować nadmiar technologii, której na co dzień używamy i modelować to, czego używamy, ale w głowie. Takiego DDD nikt w swojej organizacji nie zabroni ci stosować. Domain Drivers, w przeciwieństwie do innych naszych bohaterów, nie rozmawiają też o architekturze wdrożeniowej, czyli np. czy to jest funkcja, czy to jest lambda, czy to jest moduł, czy mikroserwis - to nie są pytania, które byłyby w tym miejscu istotne.

Problem jest z zamkniętym pudełkiem harmonogramu, więc decyzję wdrożeniową będzie można ewentualnie w przyszłości zmienić. Podejmowanie jej teraz jest zbyt ryzykowne. To, czego łatwo nie będzie można zmienić, to separacja pomiędzy warstwą grafu i warstwą, która mówi językiem planowania projektu. I to jest to, o czym dyskutują Domain Drivers. Po podjętej decyzji zabezpieczają ją testem architektonicznym. I w ten sposób słownictwo związane z harmonogramem nie wpadnie już do tej warstwy grafowej. Całość eksperymentu do tej pierwszej wersji kodu to były jakieś 3 godziny

Na pewno nie miałoby to sensu, gdyby ta praca zajęła przykładowo tygodnie. A tak swoją drogą, czy w organizacji widziałeś lub widziałaś kiedyś dział zrównoleglania? Idąc zawsze top-down i stosując takie trochę naiwne heurystyki jest dużo mniejsza szansa na to, że odkryjemy przedstawiony tutaj Deep Model.

[MateuszNaKodach]

Question: topDown vs BottomUp - powtorzyc

[MateuszNaKodach]

L03. Metryki dobrego modelu - brakujące narzędzie rozwiązujące "moje jest mojsze niż Twojsze" [17:18]

Mało ważna lekcja, niezbyt konkuretów.

Reprezentacja modelu:

[MateuszNaKodach]

L04. Deep Model: Optymalizator [17:50]

Zobacz, gdybyśmy mieli z
jednej strony pulę zasobów, a z drugiej strony pulę projektów i zależy nam na
efektywnym żonglowaniu, tymi zasobami pomiędzy projektami. Ale właściwie nie
chodzi o zasoby, bo zobacz, zasób ma tak jak gdyby przyczepione do siebie
oferowane umiejętności, a projekt ma jak gdyby w sobie takie sloty do zapełnienia
tymi umiejętnościami. Czyli nie chodzi właściwie o te zasoby, tylko o ich te
umiejętności. I dalej było mówione, że projekt ma szansę, aby się udać, kiedy nie ma
brakujących umiejętności w okresie trwania etapów tego projektu. A tak sobie myślę,
że równolegle przecież ta pula zasobów może się zwiększać lub zmniejszać. Z wielu
powodów, bo coś jest dokupowane, coś się psuje, ktoś się czegoś douczy.

Niewazne co sie dzieje (np. L4) - to tylko dodajemy/usuwamy zasób z póli.

[MateuszNaKodach]

L05. Zadanie [05:54] + Rozwiazanie

Jak nie wiesz, co robić, to rób, co wiesz. Postaraj się szukać analogii do innych problemów. Dużo łatwiej jest rozwiązać problem, który chcesz rozwiązać, jeśli sprowadzisz go do problemu, który wiesz, jak rozwiązać. Będziemy to powtarzać jeszcze kilkukrotnie. Niektórzy tego typu problemy widzieli i rozwiązywali, więc będą dla nich proste. Reszta z nas musi się jakoś posiłkować. I tutaj samo przejrzenie spisu treści książek o algorytmach albo o archetypach może pomóc. Samo przejrzenie spisu treści.

Wniosek o tym, że wiele problemów można sprowadzić do znanych problemów i wniosek o tym, że żeby je sprowadzić do tych znanych problemów, to muszę wiedzieć wśród jakich znanych problemów mogę w ogóle szukać.

[MateuszNaKodach]

L06. Modelowanie Niepewności i Rozwiązania Zadania [17:00]

kiedy biznes mówi “nigdy”, albo kiedy mówi “zawsze”. Doświadczony modelarz wie, że to
oznacza po prostu - “na razie nie znamy takiego przypadku”, albo “zawsze, za wyjątkiem
sytuacji, kiedy nie”.
Domain Drivers postanowili zamodelować tę niepewność poprzez separację algorytmu i
słownictwa plecakowego od słownictwa projektowego. Możesz to znaleźć pod git tagiem
agnostic-knapsack. Separacja pomaga odkryć czasem wcześniej ukryte założenie, które
mamy w generycznej strukturze. Bo to założenie musiało być uwypuklone w generycznym
algorytmie.
Zwróć uwagę na tok myślenia bohaterów. Starają się oni wyłapać zmienne i niepewne
założenia. I tak modelują rozwiązanie, żeby przyszła zmiana nie była bolesna. Wbrew
pozorom nie jest to łamanie zasady YAGNI. Oni nie implementują żadnych przyszłych
wymagań. Małym kosztem przygotowują tylko model na zmianę. Model, który i tak musi być
zaimplementowany, a prawda jest taka, że takie uogólnianie i szukanie części stabilnych
powoduje, że robią to szybciej, niż gdyby ślepo podążali zasadą YAGNI i literalnie
implementowali tylko kilka obecnych wymagań biznesowych za pomocą tego modelu
specjalistycznego.```

[MateuszNaKodach]

L09. Model jest wszystkim czego potrzebujesz [10:37]

Ludzie mają niesamowity talent do łączenia ze sobą rozłącznych koncepcji, tylko dlatego, że pewne nazwy brzmią tak samo

[MateuszNaKodach]

L02. Event Storming Process Level - wprowadzenie [22:34]

Okradaniem klienta i marnowaniem czasu jest próba
modelowania procesów tam, gdzie ich nie ma. Procesów może nie być z uwagi na
nieprocesową domenę lub z uwagi na to, że biznes jest po lewej stronie Cynefin i w
organizacji procesy jeszcze się nie wykrystalizowały. Co nie wyklucza, że z twoją
pomocą, z czasem, się nie wykrystalizują. 

Z poprzedniej części wiesz, że pierwsza faza stormingu procesowego może, a nawet
musi, wyglądać chaotycznie. Być może pracujesz w organizacji, w której osoby
zapraszane na tym etapie charakteryzują się liniowym, przyczynowo-skutkowym
myśleniem. Będą zadawać pytania: Jaki jest harmonogram, nie plan spotkania, jaki
jest cel. Dla takich osób pierwsza faza dywergentna będzie wyglądać i kojarzyć się z
chaosem, mogą czuć się niekomfortowo, czy nawet opuścić spotkanie. A jeśli nie
opuszczą, to raczej nie będą mieć dobrego zdania o samej metodzie. Dlatego
wówczas koniecznie zacznij od narysowania tego rysunku i antycypowania krytyki
mniej więcej tymi słowami: Wiemy, że pierwsza faza może wyglądać na chaotyczną,
ale jej struktura jest częścią większej metodyki. Po to, aby przyspieszyć projekt i
zredukować ryzyko oraz wyszukać gotowe rozwiązania, potrzebujemy, aby teraz
wejść na krótką fazę myślenia rozbieżnego

Oczywiście nie potrzebujesz takiej fazy eksploracji, kiedy modulujesz stan AS IS.
Jeżeli będzie to pierwsza sesja stormingowa, w jakiej będą uczestniczyć
przedstawiciele tzw. biznesu, to musisz zadbać o gładkie wprowadzenie. Po
zakomunikowaniu celu spotkania, wprowadź notację, ale rób to stopniowo. Zacznij
od zdarzeń. Wyjaśnij, że chodzi o istotne wydarzenia w procesie. Istotne, czyli takie,
które wpływają na kolejne wydarzenia. Wpływają to znaczy, że coś później może się
nie wydarzyć lub wydarzyć się nieco inaczej. Z

PIVOTAL EVENTS

Zdarzenia pivotowe to jak gdyby kamienie milowe w procesie. Poznasz je po tym, że
nie jest łatwo je powtórzyć albo wycofać. A wycofanie to osobny proces. Np. aby
wycofać zatwierdzenie zamówienia, wymagany jest proces zwrotu.

Procesowe (if, rozglazienie):

[MateuszNaKodach]

• [ ] TODO: powtorzyc analize Bottom-Up i CYNEFIN https://edu.devstyle.pl/products/domain-drivers/categories/2155259034

[MateuszNaKodach]

L04. Porady dla facylitatorów [17:21]

Jeżeli widzisz, że zdarzenia nie wnoszą nic do komend, to albo masz dziedzinę płytką i operacje typu CRUD, albo musisz jednak poświęcić nieco więcej czasu, aby dojść do sedna.

Modelując rzeczywistość możesz zadać pytanie o to, czym to jest, czyli struktury danych, jak to się zachowuje, albo w co to się zmienia. W nowoczesnym podejściu, wprowadzonym na początku wieku, z powodu gwałtownej rekrutacji do fabryk oprogramowania, zaczęto promować proste podejście skupiające się jedynie na strukturach danych. Jakie sensowne pytania możesz zadać, gdy modelujesz struktury danych? Co ma projekt? Projekt ma etapy. Co mają etapy? Inne etapy. Co jeszcze ma projekt? Nazwę. A ile znaków ma minimalnie nazwa? Czy czujesz, że przybliża cię to do zrozumienia tego biznesu?

Kiedy modelujesz zachowania,możesz zadać znacznie więcej sensownych pytań. Kto to zmienia? Dlaczego ten ktoś to zmienia? Jaki jest powód zmiany, czyli co musiało się zadziać wcześniej? Jaki jest skutek tej zmiany, czyli co zachodzi później? Jak często się to zmienia? Czy zmianę można powtórzyć lub wycofać oraz jak łatwo? W ten sposób masz szansę odkryć istotne elementy procesu. Zwróć uwagę, że nie musisz nawet dobrze rozumieć domeny, o którą pytasz. Możesz pokazywać palcem lub kursorem na karteczki i używać zaimków. Kto TO zmienia? Dlaczego TO się zmienia? Czasem dostaniesz zdarzenie bardzo ogólne, jak nasze przykładowe “zdefiniowano datę” i musisz drążyć w dół, jaki jest tego skutek. W ten sposób możesz dopytać, na co wpływa to zdefiniowanie daty projektu. Dopiero sterując takimi pytaniami dowiesz się, że wpływa to na datę etapów i datę końca. Ale czasem jest odwrotnie. Dostajesz bardzo szczegółowe zdarzenie i chcesz dowiedzieć się, dlaczego ono jest ważne i w jakim większym procesie uczestniczy. Modelarz musi być jak dziennikarz śledczy. Musisz dopytywać o to, co jest pomiędzy wierszami. Modelowanie aspektów Becoming przyda nam się później podczas destylacji modeli i tzw. agregatów.

Modelowanie AS IS i TO BE:

Jeżeli celem analizy procesów jest stworzenie ich na nowo, ponieważ np.
konkurencja nas wyprzedza, wtedy zawsze stwórz dwa modele: AS IS i TO BE.
Oczywiście nie ma wartości w modelowaniu procesów całego systemu AS IS. Na
sesji Big Picture wybierz obszary, na których się skupimy. Posiadanie dwóch modeli
jest ważne, ponieważ ludzie z tzw. biznesu zazwyczaj myślą o celach, o tym, co
może być lepiej. A to, co już jest zrobione, nie ma takiego znaczenia. Natomiast
ludzie techniczni, a takimi mogą być też eksperci domenowi, często myślą o
problemach w tym, co już jest. Jeżeli nie stworzysz dwóch modeli, AS IS i TO BE, to
skończysz z miksem tych dwóch światów. Po stworzeniu dwóch modeli poproś
osoby z tzw. biznesu, aby wskazały części procesu, które warto refaktorować, a
osoby techniczne, aby w tych wskazanych przez biznes częściach wskazały to, co
łatwo refaktorować.

---

Będąc dalej w kontekście refaktoringu, zauważamy, że jeżeli poprosisz
zespół o zaprojektowanie części rozwiązania na nowo, to zwykle pojawią się lokalne
i mało istotne zmiany, ale generalny kształt modelu zostanie podobny. Przykładowo,
lepiej nazwiemy coś, co nazywaliśmy na szybko, pokracznie, np. Klasa zlecenie bez
zlecenia, dziedzicząca po zleceniu. Ona dostanie lepszą nazwę, ale dalej będziemy
błędnie zakładać, że zlecenie jest nieodzowne. Dzieje się tak dlatego, że
opowiadamy nowe historie używając znanych rzeczowników. Zauważ, że główny
środek wyrazu - zdarzenie, to czasownik w czasie przeszłym trybu dokonanego.
Czyli skupiamy się na minimalnej liczbie kroków potrzebnych na dojście do celu.
Opowiadamy historię czasownikami, a nie rzeczownikami, przez co jest większa
szansa na nowy, lepszy model.

---

Diagramy architektury takich systemów zawsze wyglądają tak samo. Prostokąty połączone do jakiegoś rodzaju szyny komunikacyjnej lub same ze sobą. Są to diagramy statyczne, czyli pokazują, którędy będą płynąć komunikaty, które system będzie przesyłał. Niestety, dopiero kiedy nałożysz na ten rysunek konkretne komunikaty, zdarzenia i komendy, ujawni się plątanina połączeń. A kiedy przeanalizujesz treść tych komunikatów, widzisz przeciekanie modeli, które prowadzi, w razie potrzeby jednej zmiany biznesowej, do kaskady zmian technicznych i synchronizacji wielu zespołów. Tak więc poproś swojego uber-architekta, aby nałożył na swoją architekturę proces biznesowy, np. w postaci karteczek z event stormingu.

---

Wnioskiem ze spotkania może być potrzeba przeprowadzenia rzetelnej analizy biznesowej i wyprowadzanie tego, jak działa organizacja, zanim zajmiemy się analizą systemową i tworzeniem rozwiązań, które jedynie usztywnią aktualne błędy procesowe. To, że mamy model procesów, który chcemy zaimplementować przez dłuższy czas, nie oznacza, że nie możemy iterować.

[MateuszNaKodach]

L05. Cyrk na kółkach [03:17]

Eric Berne, twórca psychologii transakcyjnej, opisał w swojej pierwszej książce “W co grają ludzie?” około 30 gier, w jakie wchodzimy podczas interakcji z ludźmi. To, co właśnie miało miejsce, to klasyczna gra nazwana przez Berne “I tu cię mam, su***synu” W tej grze mamy atakującego i atakowanego. Atakujący doprowadza atakowanego do popełniania błędu, aby móc go lub ją przyłapać na popełnieniu błędu i dostać wypłatę emocjonalną. W tę grę lubią grać osoby, które obawiają się niekompetencji. Niestety nie wszyscy cenią sobie prawdę. Osoby żyjące w lęku przed utratą kontroli chcą mieć kontrolę, niekoniecznie będąc zgodnym z prawdą. Osoby żyjące w lęku przed odrzuceniem nie chcą prawdy, jeżeli zmniejszy to ich akceptację.

[MateuszNaKodach]

L06. Elementarz Komunikacji [14:12]

Zacznij od postawienia pozytywnej intencji, czyli takiej, z której skorzystają wszyscy. Przykładowo powiedz to w ten sposób: ok, tak jak o tym opowiadasz, pozwala nam zacząć myśleć o temacie. Ale po to, żeby lepiej zrozumieć, oszacować, zredukować ryzyko... - i to jest ta pozytywna intencja,

[MateuszNaKodach]

L02. Podział strategiczny - pojęcia [36:56]

Niestety, Domain-Driven Design magicznie tych problemów nie rozwiązało. Ale podpowiada na co zwrócić uwagę. Zwrócić uwagę na zależność pomiędzy kontekstowymi modelami plus na driver architektoniczny pojedynczego źródła prawdy. A propos driverów architektonicznych. Z punktu widzenia rozwiązania czasem będziemy dążyć do stworzenia autonomicznych modułów, będzie to nasz główny driver architektoniczny, ale nie jedyny. Przez autonomię będziemy rozumieć np. niezależność na poziomie organizacji pracy zespołów, czyli możliwość wprowadzenia zmiany bez oczekiwania na innych, ale też niezależność procesu wydawania i wdrażania, odporność na awarie, na błędy w innym module - one nie powinny zatrzymywać działania mojego modułu, możliwość niezależnego eksperymentowania biznesowego - pomysły jednego obszaru nie powinny być hamowane przez jakiś inny obszar.

---

Jeżeli optymalizujesz podział systemu pod odczyty, to będziesz mieć problem spójności przy zmianach danych w wielu miejscach oraz zmianach logiki przez wiele zespołów na potrzeby jednej zmiany biznesowej.

---

Jeżeli podzielisz system grupując rzeczowniki w hierarchiczne struktury, wówczas proste operacje CRUD będą łatwe, ale dla nietrywialnej logiki skończysz z tym samym problemem.

---

Najpierw rysujemy prostokąty, a później martwimy się o integrację pomiędzy nimi. W razie niepowodzenia zaczynamy od nowa, a kończymy, kiedy skończy się czas na projektowanie. Czyli jak gdyby próbujemy symulować to, co może zadziać się w przyszłości z wymaganiami funkcjonalnymi i niefunkcjonalnymi. Z tym, że robimy to nieracjonalnie i chaotycznie.

Najpierw zobaczmy, jakie byłyby interakcje, a później zamknijmy je w prostokąty, tak aby zmiany stanu, które muszą być spójne atomowo, miały miejsce wewnątrz prostokątów oraz tak, aby zredukować ilość strzałek, czyli komunikatów.

---

Hheurystyka, jaką podaje Evans, to tworzenie mniejszych modeli kierując się analizą lingwistyczną. W skrócie polega ona na szukaniu znaczenia słów w osobnych kontekstach znaczeń językowych. Dlatego też kontekst ograniczony (bounded context) możemy rozumieć jako jedną z heurystyk służących do separacji modeli, co dla niecierpliwych wyjaśniliśmy już w drugim tygodniu tego szkolenia. Czyli gdyby podówczas jedyną znaną heurystyką było przykładowo szukanie głównych pytań biznesowych, a nie analiza lingwistyczna, to dziś mówilibyśmy: ograniczony pytajnik? No, bardzo prawdopodobne. Zachęcamy, aby mówić po prostu model zamiast bounded context. Model, który ma sens w określonym kontekście. Bo właśnie, modele enkapsulujemy w osobnych modułach. Miej w głowie nadrzędny cel, czyli autonomiczne modele. Nie poddomeny, nie konteksty, tylko autonomiczne modele.

---

Czy da się wszystkie poddomeny zaprojektować przy pomocy jednego modelu? Na studiach się udawało, w tutorialach też. Mamy jeden pakiet encji, czy jeden schemat danych i po prostu część rzeczowników przynależy mentalnie do poddomeny pierwszej, a inna część do drugiej, i tak dalej - proste. Do momentu, kiedy nie pojawią się nietrywialne operacje i każda poddomena potrzebuje zmieniać dane w innych, a do tego ma specyficzne wymagania co do modelu. I wtedy wbijamy kwadrat w okrągły otwór.

---

Przestrzeń pojęć i reguł tego modelu nazywamy bounded contextem, czyli innymi słowy kontekst ograniczony to kontekst, w którym dany model ma sens.

---

Tak więc w tym wypadku mamy jedną rzeczywistość, ale wiele możliwych modeli, tworzonych po to, aby łatwiej i bardziej adekwatnie zadawać specyficzne pytania. Powtórzmy to jeszcze raz. Model tworzymy pod kątem pytań, jakie chcemy postawić. W nietrywialnych systemach mamy wiele specyficznych pytań i możemy tworzyć osobne modele nawet do tych samych obszarów rzeczywistości.

[MateuszNaKodach]

L03. Heurystyka: główne pytania [29:08]

Najpierw przeanalizuj aspekt
behawioralnych zmian stanu i interakcje, a później zamknij je w hermetycznych
modułach.

Wypisz aktorów i aktory, jakie będą korzystać z systemu. Dla każdego z nich zapytaj tzw. biznesu na jakie pytania będą ci aktorzy i te aktory szukać odpowiedzi. Użyj innego koloru dla każdego z pytań. Sprawdź, czy pytania są faktycznie istotne, czyli w ilu miejscach procesu są zadawane, jak często są zadawane oraz czy wpływają na cele strategiczne. Dalej poproś tzw. biznes aby oznaczył kolorem te pytania, zdarzenia, które wpływają na odpowiedź na te pytania. Przypomnijmy, że zdarzenie jest to zmiana stanu, niekoniecznie komunikat na brokerze. Widzisz już, że zdarzenia wpływające na niektóre pytania zachodzą w wielu miejscach procesu, często oddalonych od siebie o dosłownie metry na rysunku. Dalej zapytaj, które zdarzenia muszą zajść atomowo, aby wiedzieć, które z nich musisz zamknąć w hermetycznych modułach, a które mogą napływać np. asynchronicznie w postaci komunikatów. O

[MateuszNaKodach]

L05. Heurystyka: Pivotal Events [11:17]

W językach klasowych to właśnie osobne klasy służą do wyrażania modeli, które mają inne operacje, inne reguły oraz inne dane. Nie można powiedzieć, że ktoś tworzy zbyt dużo klas. Tworzymy ich tyle, ile wymaga natura modelowanego biznesu. Ktoś może powiedzieć - trzymaj mi yerbę, w każdej metodzie dodamy if status equals, np. reservation, then throw IllegalOperationException. Tak, też oczywiście można i nawet to będzie działać kiedy nad kodem pracuje jeden zespół lub kiedy zespołów jest więcej, ale zmiany nie są częste. Będzie to wtedy działać. Tracimy wówczas wyrazistość modelu, ale tracimy też możliwość łatwego manipulowania procesem.

Zmiana istoty rzeczy, jako osobna klasa, bez wglebiania sie w 8tys.

[MateuszNaKodach]

L04. Heurystyka: alternatywy w przebiegu procesu [16:08]

zmiana procesów wraz ze zmianą managementu, po to, aby pokazać pracownikom, kto obecnie rządzi.

Reguły wynikające np. z regulacji będą zmieniać się znacznie rzadziej, oczywiście jest grupa reguł, jak na przykład dynamiczne cenniki czy rabaty, które mogą zmieniać się bardzo często, ale nie są to reguły procesowe, a dziedzinowe. Nimi zajmiemy się w części taktycznej.

a. Zmapowane do tej pory procesy to tylko jakiś specyficzny, ale prawdopodobnie najczęstszy sposób przejścia przez te reguły. Usztywnienie modeli, aby wspierały chwilowy kształt procesu, usztywnia architekturę. Do tego możemy przeoczyć gotowe, sprawdzone, archetypowe rozwiązania.

Nie zmienia sie prawo, ale np. zmienia sie proces, ktory te reguly orkiestruje, aby zapewnic.

[MateuszNaKodach]

---

Generalnie heurystyka jest taka - jeżeli widzisz sytuację, kiedy wiele domen wpływa na wiele innych domen, to prawdopodobnie przeoczyliśmy jakąś domenę pomiędzy nimi. W naszym wypadku będzie to scoring czy reputacja klienta, którą można zgeneralizować do scoringu czegokolwiek. To tylko kwestia konfiguracji reguł liczenia tego scoringu. Czyli wiele domen wpływa na scoring, A scoring wpływa na wiele innych domen.

---

Bez odkrycia scoringu mielibyśmy orgię mikroserwisów oraz paraliż zmian w zespołach, czyli rozproszony monolit. Dzięki scoringowi masz jedno miejsce, gdzie trzeba zmienić logikę w razie potrzeby. Model danych możesz oprzeć o event sourcing, czyli zapis zdarzeń zamiast aktualnego stanu, co pozwoli ci podróżować w czasie, czyli poradzić sobie ze zmianami logiki typu: scoring liczymy nie co kwartał, a co miesiąc. Jeżeli masz zdarzenia wpływające na scoring w jednym miejscu, to zawsze możesz przeliczyć scoring od nowa lokalnie.

[MateuszNaKodach]

L08. Destylacja kontekstów: dwukierunkowa analiza lingwistyczna [29:12]

To, że jakiejś poddomeny nie odkryliśmy, nie oznacza, że ona zniknie. Na poziomie rozwiązania będzie niejawnie zaimplementowana jako magiczne statusy, jako ify do special case'ów, jako plątanina komunikatów pomiędzy modułami, co było widać w naiwnych rozwiązaniach Dung Divers.

---

Jak już wiesz, w Domain-Driven Design chcemy tworzyć modele odpowiednie do klasy problemu. Modele mają sens jedynie w ograniczonych kontekstach, czyli z angielska bounded contexts. Poddomeny odkrywamy, ale bounded contexty wymyślamy

---

Jak wspomnieliśmy na początku tygodnia, wygodniej jest myśleć o osobnych modelach, zamiast mówić bounded context optymalizacji kosztów, bounded context symulacji projektu, lepiej mówić model optymalizacji kosztów, model symulacji projektów albo model czegoś w kontekście optymalizacji kosztów, model czegoś w kontekście symulacji projektów.

---

mówić po prostu o osobnych modelach, o autonomicznych modelach, o modelach wyspecjalizowanych do rozwiązywania konkretnych zadań.

---

Czy taki sam model zasobu potrzebujemy w obu tych kontekstach? Oczywiście, że nie. Będą nam potrzebne inne dane i inne reguły. Jedynie ID będzie takie samo. Czyli na poziomie rozwiązania będziemy mieć różne klasy Resource, czy też klasy Project, z różnymi metodami wchodzące w interakcje z innymi typami.

---

Widzisz już klasę Ogłoszenie z zagnieżdżonymi ifami po wielowymiarowych
statusach i eksplozję kombinatoryczną przypadków testowych? To ludzie ludziom ten
los zgotowali. Pół godziny analizy poddomen wystarczyło, aby znaleźć prosty
i klarowny model.

amy szablony ogłoszeń, którymi handlujemy. Z szablonu tworzymy produkt reklamowy i po sprzedaży produktu zlecamy jego realizację. Zmiany na każdym z etapów skutkują, albo i nie, zależnie od reguł, zmianami na etapach poprzedzających i następujących, co było łatwe do wykrycia zdarzeniami piwotującymi i pytaniami facylitującymi. A jeżeli udało ci się już zaopatrzyć w książki o archetypach modeli biznesowych, to prawdopodobnie widzisz już archetypy takie jak szablon produktu, instancja produktu oraz zlecenie.

---

Ale duzi chłopcy i duże dziewczynki wiedzą, że jeżeli tzw. biznes mówi: nigdy, to znaczy: na razie bardzo rzadko, a kiedy biznes mówi: zawsze, to znaczy: na razie bardzo często. Dlatego w sekcji taktycznej będziemy grać w defensywie, aby przygotować się na zmiany reguł gry i zmiany granic. Bo rolą projektanta jest zredukować ilość decyzji, których zmiana jest kosztowna

[MateuszNaKodach]

czym jest model? Model jest wspólnym artefaktem komunikacyjnym. Jest też ustrukturyzowanym wyobrażeniem o rozwiązywanym problemie. Model definiuje słownictwo używane w systemie, dokumentacji i w konwersacjach. Ten język to kolejny bardzo ważny artefakt zdefiniowany przez Evansa, czyli wszechobecny język, który jest platformą komunikacyjną. Model jako wspólna płaszczyzna porozumienia jest bazą wiedzy o tym, jak działa biznes w połączeniu z IT. Sam model dziedziny może przyjmować formę diagramu, przykładów kodu lub nawet pisemnej dokumentacji. Ważne jest, aby model był dostępny i zrozumiały dla wszystkich tych, którzy są zaangażowani w projekt.

Model nie odwzorowuje też rzeczywistości, tylko nasze wygodne spojrzenie na tę rzeczywistość. Przecież w prawdziwym świecie nie istnieje coś takiego jak DecisionSupport. Dodatkowo mogę wygenerować kilka modeli tego samego problemu. Jak mówi słynny cytat: wszystkie są nieprawdziwe, ale niektóre są użyteczne. Tej użyteczności chcemy cię uczyć, podając różne metryki oceny modelu.

[MateuszNaKodach]

[MateuszNaKodach]

L02. Mapa Kontekstów (Mapa Zależności Między Modelami) - Twój najważniejszy artefakt [13:19]

Jeśli masz zapamiętać jedną rzecz z tego szkolenia, niech to
będzie: stwórz taką mapę na ścianie w przestrzeni, gdzie spotykają się zespoły
z tzw. biznesem i z personelem zajmującym się ceremoniami oraz pilnuj, aby
wszystkie decyzje architektoniczne były podejmowane przy tej mapie.

Jest też świetnym artefaktem walidacji pomysłów dla
Product Owner-ów, bo widać na niej, co można by zbudować z obecnych elementów
tego systemu. Widać np. capability, co stymuluje pomysły na ich sprzedaż, dodając
warstwę produktową i oczywiście polepszając swoje KPI-e.

Nie chodzi o to, żeby powiedzieć, że wszystkie te projekty to inne modele z innymi danymi. Na mapie widać jak na dłoni wzorce tej integracji. Widać też relacje międzyzespołowe. Czyli za pomocą tej mapy odpowiem na przykład na pytania: czy to kontekst symulacji polega na modelu z alokacji, czy na odwrót? Czy to Planning wie o alokacjach i tam rozpoczyna kolejne etapy, czy na odwrót? Czy może robi to jeszcze inny, nadrzędny trzeci kontekst? A te dwa wspomniane w ogóle o sobie nie wiedzą. Dlatego też mapa modeli to najważniejszy artefakt dokumentujący system. Bo chociaż programiści i programistki nie zawsze mają bezpośredni wpływ na jej kształtowanie, to odczuwają jej konsekwencje w codziennej pracy. A to wpływa na tempo dostarczania. Dlaczego najważniejszy artefakt? Bo tylko mapa modeli wykrywa pewne dysfunkcje, które nie są widoczne albo są słabo widoczne na samej liście modułów oraz praktycznie niewidoczne na pięknych prezentacjach z managementu. Bo lista nie pokazuje relacji, więc na liście nie zobaczysz na przykład, że poprzez prawdopodobnie zbyt silną zależność dwa konteksty zaczynają odpowiadać na te same pytania, co powoduje rozmycie odpowiedzialności i brak sprawczości zespołów. A Product Owner nie wie, do kogo ma pójść, żeby zaimplementować nowy pomysł. Dodatkowo zespoły są od siebie silnie zależne i razem muszą priorytetyzować swoje tzw. backlogi, co, jak możesz pamiętać, dotknęło naszego entuzjastę.

---

HRYDRA HEROES 3!!! Wzorzec Customer-Supplier może też doprowadzić do pewnej dysfunkcji. Wyobraź sobie następującą sytuację. Zespół jest upstreamem i tylko upstreamem. Dostarcza usługi na zamówienie, czyli w teorii nie zależy od nikogo. Ale jest w tej relacji Customer-Supplier z czterema różnymi zespołami. Mottem i dramatem tego zespołu będzie żonglerka priorytetów. Głównym narzędziem z kolei board na JIRA. Większość pracy to priorytetyzacja zamówień innych zespołów. Dodatkowo też ustalanie, które prośby są istotne, a które mniej, a które to w ogóle się wykluczają. Pewnie będzie wyznaczona rotacyjna funkcja sprzątającego nieporządek w JIRA. Czyli w teorii jesteś upstreamem, bo od nikogo nie zależysz, ale w praktyce, globalnie, to jesteś trochę downstreamem. I takie rzeczy też wyłapię, zazwyczaj tylko na tej mapie modeli, bo w kodzie tego po prostu nie widać.

[MateuszNaKodach]

L04. Logiczne poziomy integracji kontekstów [28:49]

Jesli zmienie command na event, a nie zmienie logicznej zaleznosci, to niewazne. Np. commadn - daj symulacje na event poproszono o symulacje, a mowie to w alokacji, to dalej mowie tym jezykiem, czyli przenika model.

Jesli znasz kolejny krok procesu to uzyj command albo query. Moze byc sync/async.

I ma tylko połowiczną rację, bo jak już w tym tygodniu wspomnieliśmy, zamiana fizycznego kierunku przepływu informacji automatycznie nie zmienia logicznego przepływu informacji

TODO: fajne rozkimny, mozna jeszcze raz obejrzec

[MateuszNaKodach]

Lepsza zasada niz SOLID:

[MateuszNaKodach]

L07. Łączenie klas problemów [15:55]

Operations - wykorzystanie potencjalu, np. zapalenie swaitel drogowcych, ale moge nizej wlaczyc, ktore chce, roznie je wykorzystywac. Albo potencjal przewiezienia.

Poziom Operations zawiera klasy modelujące konkretne operacje, jakie aktualnie wspiera nasz system na bazie potencjału. Od strony technicznej nie chodzi tutaj o dziedziczenie po klasach z poziomu capability. Chodzi o wywołanie metod z poziomu capability z pewnymi charakterystycznymi dla poziomu operacji parametrami lub w pewnej kolejności logicznej. Model na tym poziomie to transformaty lub zmiany stanu. Dla przykładu umieścimy tutaj proces zakupów oraz reklamacji. Są to konkretne operacje, jakie zbudowaliśmy nad modelem potencjału, produktami, klientem i pieniędzmi. Poziom polityk niejako dostraja poziom operacji. Obiekty lub funkcje na poziomie polityk modelują wariacje operacji biznesowych. Są to transformaty. Warto zauważyć, że polityki na poziomie technicznym to domknięcia operacji. Jako przykład na tym poziomie mamy różne implementacje domknięcia operacji, różne sposoby liczenia rabatu oraz różne sposoby automatycznego rozpatrywania reklamacji.

[MateuszNaKodach]

L01. Czy to jeszcze CRUD czy już rywalizacja o zasoby? [19:00]

Dobrym sposobem na zrozumienie, czy mam problem z rywalizacją o zasoby, czy jednak z problemem notatki jest, oczywiście po analitycznych pytaniach, dokonanie właśnie takiego technicznego sprawdzenia. Technicznego sprawdzenia, które mówi, czy instrukcje warunkowe potrzebują danych, które mogą być w trakcie sprawdzania tych instrukcji zmieniane. Jeśli nie, to jedynym problemem jaki mogę wtedy mieć, to nadpisywanie stanu notatek - i wracamy do początku problemu. Czy wtedy ten lost update jest problemem? Odpowiedzieliśmy, że zależy od intencji ale w dzisiejszym świecie zapobieganie tego typu anomaliom jest jednak tak proste, że zazwyczaj po prostu się je robi bez analizy tej intencji. Chyba że mamy bardzo, bardzo wyśrubowane wymagania co do skalowalności systemu, który ma blokować użytkowników na przykład jak najrzadziej.

Po to był ten cały wstęp. Bo często widzimy agregaty w miejscach gdzie mamy CRUD-y. I różnica w wymaganiach, która determinuje klasę problemu wbrew pozorom może być bardzo drobna. Zauważmy, że wymaganie brzmiało: projekt nie może być wystartowany z niepoprawnie zaplanowanym harmonogramem. Takie wymaganie może być zaimplementowane regułą walidacyjną, a nie regułą chronologii. która sprawdza przeszły stan, który na czas sprawdzenia może być zmieniony przez inny wątek. Jeśli zrozumiem, że to jest walidacja, to wtedy separuje się od tego, że gdzieś kiedyś tam była notatka i transformata licząca harmonogram

[MateuszNaKodach]

L02. Dlaczego w agregatach nie chodzi o obiektowość? [33:40]

Często podawanym argumentem przewagi jednego stylu jest: no, obiektowe to jest lepsze, bo jest obiektowe. Używasz języka obiektowego, to programuj obiektowo. To już trochę omówiliśmy przy transformatach. Obiektowe nie znaczy lepsze. Obiektowe znaczy obiektowe. Obiektowe jest lepsze jak problem jest obiektowy. Czyli na przykład jak problem musi zarządzać stanem. Stanem, który trzeba zapamiętać i którym trzeba jakoś zarządzać.

---

Żeby argumentować rozwiązania obiektowe, trzeba jednak odnieść się do tego ponownego użycia kodu. I kluczowym aspektem jest tutaj aspekt komunikacyjny i model mentalny, jaki moja architektura pozostawia przyszłym programistom i programistkom, które będą pracować z tym kodem. W przypadku kodu proceduralnego, jako czytelnicy dostajemy elementy konstrukcyjne w postaci tabel i skryptów, czyli encji i serwisów. I dopisując nowe wymaganie, możemy zrobić je w zupełnie nowym serwisie omijając reguły. Bo przecież mamy dostęp do każdej tabeli poprzez serwis. Możemy tworzyć nowe serwisy, nowe skrypty, jeśli obecne klasy z procedurami wydają nam się zbyt długie. No bo architektura obecnego rozwiązania zachęca nas do tego. W przypadku obiektowym, jako czytelnicy kodu, dostajemy jako elementy konstrukcyjne obiekty ze stanem i z regułami.

---

Jeśli wybiorę taki kod do problemu właśnie rywalizacji o zasoby, czyli do agregatów, to proszę się o kilka problemów. Bo już na wstępie często wczytuję moją jednostkę spójności w różnych momentach w czasie. Dlaczego? Bo myśląc tabelkami, a nie obiektami, które są jednostkami spójności, mam dane rozsmarowane po wielu tabelach. To powoduje, że dane potrzebne do podjęcia decyzji mogą być po prostu wczytane jako rozsynchronizowane. To nie jest oczywiście wina kodu proceduralnego. To jest wina tego, że taki kod i branża i wiele różnych projektów przyzwyczaja nas do takiego myślenia. Taki anemiczny kod przyzwyczaja nas do tego, że mamy encję per tabelkę i często serwis per tabelkę.

---

Natomiast, jeśli reguły są rozpięte na tabelkach to musisz sięgać do tych tabelek. A przecież te wczytywane tabelki mogą w tym samym czasie być zmieniane przez inne serwisy, więc na czas operacji trzeba to jakoś zablokować. No to blokujemy i wciągamy do swojej jednostki spójności inne dodatkowe komendy, które te inne serwisy na tych tabelkach wywołują. Te inne operacje będą się blokować z tym skryptem ze slajdu. Będziemy je łączyć w większą jednostkę spójności. A jak nie stosujemy blokowania, to narażamy się na niespójność reguł i danych. No bo reguły rozpięte są na wielu tabelach i równe serwisy operują na tych samych danych. I wyszło tak głównie dlatego, bo elementy konstrukcyjne jakie mamy do implementacji, to tabele i skrypty. Czyli taki kod proceduralny utrudnia nam myślenie o granicy jednostki spójności, w szczególności, gdy ona się zmienia.

---

Kohezja

Jeśli chcemy zmaksymalizować skalowalność, to warto zapewnić jak najszybszą obsługę komendy, m.in. poprzez zaciąganie jak najmniejszej ilości danych. To dlatego właśnie chcesz mieć tzw. kohezję w jednostkach spójności, czyli w agregatach. Nie dlatego, żeby po prostu mieć kohezję, ale dlatego, żeby wczytywać jak najmniej danych przy podejmowaniu decyzji. A czym jest ta kohezja? W skrócie można określić ją jako miarę tego, jak dobrze grupujemy rzeczy, które od siebie są zależne. Nie chodzi tutaj o zależność logiczną. Jednym z rodzajów i metryk kohezji jest to, jak wiele pól używanych jest przez jak wiele metod klasy. Jeśli wszystkie pola klasy są wykorzystywane przez wszystkie metody, to wspaniale. Oznacza to, że faktycznie są wykorzystywane razem, więc wpadły w jedno miejsce. Będą razem wyciągane z bazy. Pewnie będą razem blokowane. Dlatego właśnie wpadły w jedno miejsce. I oczywiście, tak jak w Domain Drivers, lepiej być tutaj pragmatycznym. Kohezja lub jej brak jest informacją a nie celem samym w sobie. Jak kohezja jest za mała, to pewnie mam dużą jednostkę blokowania, dużo niepotrzebnych konfliktów i niewydajny system. O ile system w ogóle obsługuje walkę o zasoby. O ile tam w ogóle jest współbieżność. Bo mierzenie tego typu kohezji nie ma sensu na przykład w problemach CRUD-owych.

[MateuszNaKodach]

L04. Rodzaje blokowania i dlaczego 4 zasady projektowania agregatów to w praktyce jedna? [18:08]

Wyjątki 1 transakcji:

• batchowe tworzenie
• 1 argegat tworzy inny
• referencja do agregatu innego - bedzie sie blokowac, poszerzam jednostke blokowania, jako pole: ktos zacznie zmienac stan w metodzie.

[MateuszNaKodach]

L06. Strategia testowania, Application Services, Domain Services, Policies i inne [18:17]

Straegia w taktycznym DDD, transformata liczy transormate do zapewnienai reguł. To moze polityka np. byc jak zajmujemy miejsca w kinie - czy obok siebie ,czy musi byc miejsce oobk

Czy moge dodac serwis do agregatu? NIE. bo to problem walki o zasoby. Problem walki vs problem integracji.

[MateuszNaKodach]

L07. Podsumowanie podstaw i zadania praktyczne [17:48]

Agregat to wzorzecz blokady odpowiednich zasobów, wynikajacyhc ze wspolbieznosci

Przykład zaprojektuj jednostki spojnosci:

Nie ma problemu wspolbierznosci, bo jeden czlonek rodziny rejestruje do swojego portfela. Ale moze ktos rejestrowac z kilku urzadzen jednoczesnie, wtedy jest wspolbieznosc. Agregat przyjmuje fakty, wallet o niczym nie decyduje, to czlonek rodziny podjal decyzje o wydaktu, a teraz o tym informuje. Wallet jest transformata, patrzy czy zostala przekroczona kwota.

Czy ma sens takie kupowanie jednostek jako agregat, jesli tylko ja moge je kupic?

Strategia moglbyby byc kiedy decyzja wchodzi w zycie i powstaje portfel, tutaj jest glowsowanie - tam agregat, czy nikt nie zaglosowal wiecej niz raz.

Super przykład lekraza i głosowań!!! Można robić model i coś co wygląda jak agregat.

[MateuszNaKodach]

L08. Zaawansowane agregaty dynamiczne: Kiedy obiektowe agregaty nie wystarczają [22:04]

Agregat dynamiczny - super przyklad!!! OGarnac dokladniej!