DomainDrivers

[MateuszNaKodach]

Rozszerzona mapa kontekstów.

[MateuszNaKodach]

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.