Po spotkaniu Architektów
Krzysztof Jelski
Jakub Nabrdalik
> Nie mogłem wczoraj być z wami, ale prezentację oglądałem wcześniej.
> Ciekaw jestem waszych wrażeń, myśli, wniosków.
IMHO brakowało przykładu. Takiego case'a, który by pokazywał: bounded
context ustaliliśmy taki to a taki, ponieważ to i tamto. Wyszło fajnie
bo tak i tak, praktyczny zysk przez zmniejszenie poziomu komplikacji
jest taki to a taki.
Strasznie miękko i abstrakcyjnie wyszła ta prezentacja. Mało mięska. Ale
może po prostu głupi jestem i nic nie zrozumiałem.
> Co najbardziej zwróciło waszą uwagę? Co się wydało najbardziej nowe,
> rewolucyjne?
Książkę czytałem wcześniej, podobnie DDD bez CQRS'a próbowałem użyć (bez
CQRS'a nie warto), więc może nic odkrywczego tam mnie nie uderzyło, ale
podobało mi się zaznaczenie, że cały projekt nie koniecznie musi mieć
jedną architekturę i lepiej dobrać architekturę osobno do każdego
bounded contextu.
To jest coś czego mi wcześniej brakowało. Jeśli do tego dodać zasadę
"mieszaj tyle technologii baz ile ma sens", czyli rzeczy transakcyjne w
bazach relacyjnych (transakcyjnych), rzeczy tylko do pokazywania, w
bazach nosql'owych, etc. to o ile nie przekombinujesz liczby
technologii, może dać to bardzo fajne efekty.
Jest taki projekt Spring Data, który przykrywa bazy NoSQL'owe. Jest
wykorzystywany w Grailsach w GORMie, czyli w sumie GORM przykrywa
wszystkie technologie bazodanowe (hibernate + nosql). Pozwala to na
bardzo łatwe (przynajmniej w teorii bo nie próbowałem) wykorzystanie
różnych baz i stosowanie tego co Ci akurat pasuje do danego kontekstu (a
może nawet aggregate root'a). Jak się nad tym zastanowić, to w naprawdę
wielu projektach da się znaleźć bounded contexty które:
- w zasadzie są tylko do pokazywania (minimum logiki: np. produkty w
sklepie)
- są silnie transakcyjne i/lub zależne czasowo (tzn. czas eventów ma
znaczenie), np: zamówienia w sklepie
- są bardzo spójne wewnętrznie (np. klienci sklepu, czy inny CRM)
Każdy z context'ów prosi się o inne rozwiązanie architektoniczne.
Oczywiście wszystko zależy od use case'ów, ale pisząc oferty widzę te
use case'y przed sobą, i mam zaproponować architekturę (a priori, ale
potem mogę ją zmienić), więc to jest dokładnie punkt, w którym znajduję
bounded contexty i planuję rozwiązania.
Tak, wiem, w idealnym świecie powinienem to robić później, gawędząc
kilka miesięcy z ekspertami domenowymi :)
> Czy ktoś ma pomysł i chce zastosować jakieś idee z tej prezentacji w
> swojej codziennej pracy?
Pierwsza oferta z bounded contextami i architekturą per context, poszła
do klienta.
--
Jakub Nabrdalik
http://solidcraft.eu
Piotr Przybylak
<jak...@gmail.com> napisał:
> Pierwsza oferta z bounded contextami i architekturą per context, poszła do
> klienta.
Dziś? Mam rozumieć, że to efekt inspiracji wczorajszym spotkaniem ;> ?
--
Pozdrawiam
Piotr Przybylak
Jakub Nabrdalik
> W dniu 21 grudnia 2011 11:14 użytkownik Jakub Nabrdalik
> <jak...@gmail.com> napisał:
>
>> Pierwsza oferta z bounded contextami i architekturą per context, poszła do
>> klienta.
>
> Dziś? Mam rozumieć, że to efekt inspiracji wczorajszym spotkaniem ;> ?
Nie, poszła wcześniej (latem), zainspirowana Jarosławem Pałką i jego
nosql'owymi, mieszanymi aplikacjami. Ale dziś widzę, że to nie jest
kwestia bazy, tylko contextów.
Michał Grzejszczak
Potrzebowałem nieco czasu żeby zebrać do kupy moje przemyślenia. Tylko
zebrałem - są mało uporządkowane. Nie bierzcie nic do siebie, lubię
narzekać :)
Na początek mam uwagę odnośnie formy spotkania. Bardzo mi się podoba
pomysł, żeby oglądać jakąś prezentację, a potem dyskutować. To może
być najlepsza forma jak dla tej grupy. Jednak uważam, że znacznie
lepiej byłoby poprosić o obejrzenie prezentacji przed spotkaniem.
Spotkanie można byłoby wtedy wykorzystać na dyskusję. A tak,
spotkaliśmy się żeby posiedzieć przed rzutnikiem, za to na dyskusję
było mało czasu. Poza tym, jeśli tematyka byłaby za ciężka lub ktoś
czegoś by nie zrozumiał, to mógłby się dopytać albo coś doczytać/
obejrzeć. Dla mnie np. pojęcie CQRS było potwornie przeciążone - jak
rozumiem Udi wyjaśniał o co chodzi w jakiejś innej prezentacji, której
niestety nie oglądałem i czułem się zagubiony za każdym razem kiedy
wspominał o CQRS.
Druga uwaga odnośnie dyskusji. Myślę, że nie ma sensu ograniczać się,
szczególnie na spotkaniu 'architektów', do systemów bazodanowych. Co z
tego, że modelujesz ERD z zamkniętymi oczami, jeśli nie potrafisz
zbudować eleganckiego API dla biblioteki obsługującej np. czas i datę,
albo nie masz za grosz pojęcia o budowie programów narzędziowych.
Różne systemy stają przed podobnymi problemami, a znajomość rozmaitych
rozwiązań, ich wad i zalet oraz tego, kiedy je stosować, jest moim
zdaniem cechą dobrego architekta. Żeby jak Udi nie mówić bez przykładu
podam Eclipse (choć może jakiś ekspert Eclipse'a mnie objedzie) i np.
obiekty reprezentujące projekty. Mamy zwykły projekt dostarczany przez
platformę i powiedzmy, że JDT chce dostarczyć obiekt projektu o
naturze Java, który potrafi np. operować na classpath oraz projekt o
naturze JavaScript, który mówiąc oględnie ma dostarczać support dla
uzupełniania składni w edytorze JavaScript. Chciało by się dodać
wszystkie potrzebne metody i dane do klasy Project, bo najwygodniej
byłoby, żeby projekt, który jest i Javowy i JavaScriptowy
reprezentował jeden obiekt. Ale tak się nie da tego zrobić, bo to jest
w platformie, a JDT nie chce nic wiedzieć o JavaScript. Podobnie
sprawa ma się z plikami. Mamy zwykły plik, .java, .xml itd. Wydaje mi
się, że kwestia projektowania bounded contextów sprowadza się do
przemyślanego podziału na moduły, ale ja nie czuję się na siłach
stawiać jakichś tez w tym temacie, za to chętnie bym podyskutował,
poznał różne sposoby radzenia sobie z takimi i podobnymi problemami.
Co do samej prezentacji, to jak już wspomniałem nie rozumiałem o co
chodzi z CQRS. Nadal nie rozumiem, co oznacza, że mi się nie podobało,
bo nie znalazłem w sobie motywacji do obejrzenia wcześniejszego
wystąpienia o CQRSie. To pewnie potęguje moje odczucie, że prezentacja
była za bardzo ogólna i jedyny przykład był nadto prymitywny. Co
gorsza, nie było też negatywnych przykładów, mimo że Udi powtarzał:
"róbcie tak, bo inaczej będzie źle", a nie podał co takiego będzie
źle. Założę się, że mógłby podać wiele ciekawych przykładów tego co
nie działa. To zawsze cenna informacja.
Podobało mi się podkreślanie, że dobór architektury zależy od
przypadków użycia, ale znów zabrakło przykładów. Poza tym nie zawsze
te przypadki są znane a priori, a poza tym, jak głosi Agile, wymagania
się zmieniają. Co wtedy począć jak się nie trafiło z architekturą?
Taki Eric E. podaje np. taki przykład (z pamięci; jak ktoś lepiej
pamięta to niech mnie poprawi): "Robimy system dla firmy spedycyjnej.
Robimy, robimy i nie za bardzo wiadomo, co jest dla tej firmy
najbardziej istotne, bo wydaje się, że ekspertom domenowym wszystko
jedno. W końcu ktoś wpada na pomysł zadać pytanie: "Co Was odróżnia na
rynku spedytorów, co powoduje, że jesteście konkurencyjni?". Na to
klient: "A! Nasi klienci mówią, że nie robimy problemów, u nas zawsze
wszystko idzie gładko." Wtedy może okazać się, że przerobienie
prymitywnego, acz prostego interfejsu dla klienta spedytora na pełen
funkcjonalności, ale bardzo złożony nie było dobrym pomysłem.
Ukierunkowywanie architektury na wydajność kosztem stabilności również
itp.
Udi powiedział też coś takiego: o ile fajnie jest rozmawiać z
ekspertami domenowymi używając "ubiquitous language" to niedobrze jest
budować duże systemy zachowując strukturę wynikającą z tegoż języka
(czy jakoś tak). To dość kontrowersyjna teza ale nie pojawiło się
żadnego uzasadnienie.
> Czy ktoś z was spotkał się w pracy z architekturą podobną do opisywanej
> przez Udiego? Może pod innymi nazwami, np. SOA, ale żeby było tak, że widok
> w bardzo luźny sposób wiąże dane pobrane z różnych bounded contextów.
>
contextów. Na pewno jeden produkt używa shared kernel (dane o firmach,
itemach, zamówieniach) i dodaje w swoim kontekście zarządzanie cenami
(pricing). Pomysł żeby nie trzymać ceny w itemie jest oczywisty, jeśli
się buduje system do pricingu. Na początku czytasz przynajmniej jedną
książkę na ten temat i potem nie ma już, że item ma cenę, tylko
definiujesz od razu price-listy itp. O mieszaniu tego z innymi
elementami rdzeniowego modelu nie ma mowy również dlatego, że nie
można dokonywać zmian w podstawowej dziedzinie (tym shared kernel), bo
z niej korzystają też inne produkty. Zmiany w części wspólnej muszą
być dobrze uzasadnione i przemyślane tak, żeby były przydatne w każdym
produkcie, a nie tylko w jednym.
Acha i nie ma to raczej nazwy. Mówimy chyba "architektura" :)
A tak w ogóle, to czy mamy pomysł na kolejne spotkanie? Wyszedłem
wcześniej, więc nie wiem czy coś ustaliliście. Może jest pomysł na
jakąś inną prezentację do obgadania?
Pozdrawiam,
Michał
Piotr Przybylak
> wcześniej, więc nie wiem czy coś ustaliliście. Może jest pomysł na
> jakąś inną prezentację do obgadania?
Spotkanie moooocno się przedłużyło ale nie zostały poczynione żadne
ustalenia odnośnie kolejnych.
Podczas dyskusji po prezentacji użyliśmy naprędce naszkicowanego
diagramu klas dla systemu sprzedażowego / sklepu internetowego.
Najpierw w podejściu "klasycznym" a później z podziałem na trzy
bounded context'y . ZTCP: klienci, produkty, zamówienia (niestety
oryginał rysunku prawdopodobnie zaginął w odmentach
światecznonoworocznych porządków w Pragmatists). Myślę, że ta domena
jest dobra do ćwiczeń bo w miarę zrozumiała dla wszystkich.
Ja mam pomysł taki:
Ustalić podstawowe usecase'y które będziemy niemiłosiernie katowali
przez najbliższy czas na zasadzie podobnej do Code Retreat - tylko
może bez kasowania i na wyższym poziomie abstrakcji. Czyli dla tych
podstawych use case'ów spróbujemy przygotować implementacje dla kilku
różnych stylów architektonicznych i możemy dyskytować o ew.
wariantach.
Przygotuję repo gdzie na początkowe wrzucę wersję klasyczną
(jednowymiarową/warstwową) kotrolery/serwisy/"encje domenowe"/ a
później możemy spróbować podziału na rodzielne konteksty z
powiązaniami po id zamiast referencji, albo oddzielny stos dla
wykonywania akcji i wyświetlania danych ale CQRS.
Use case'y też pewnie trzeba będzie dopracować, ale na początek
proponuję coś takiego:
1. Klient może przeglądać towary
2. Klient może dodawać towary do koszyka
3. Klient może zamówić towary z koszyka
4. Admin może edytować towary
Mimo, że przy tak uproszczonej aplikacji cześć rozwiązań
architektonicznych może wyglądać na przerost formy nad treścią, to ja
wolałbym mimo wszystko zgłębiać je w takiej postaci, żeby móc obczaić
mechanikę danego rozwiązania bez zagłębiania się w subtelności domeny.
To pewnie mógłby być krok drugi, moglibyśmy bawić się z zmienianie
dodawanie przypadków użycia i zastanawiać się jaki miałoby to wpływ na
wybór rozwiązania.
Myślę że najbardziej produktywne będą dyskusje przy odpalonym IDE
gdzie albo będziemy wspólnie kodowali, albo ktoś będzie pokazywał na
konkretnym kodzie rozwiązanie które stosuje albo pomysł który chciałby
wypróbować.
Alternatywnie na spotkaniach moglibyśmy też analizować dostępne w
sieci przykłady dla różnych stylów architektonicznych,
jak chociażby ddd-cqrs-sample Sławka Sobótki
http://code.google.com/p/ddd-cqrs-sample/source/checkout
czy przykładowy system z książki Growing Object-Oriented Software
Guided by Tests
http://www.growing-object-oriented-software.com/code.html
Podoba mi się atmosfera małych spotkań gdzie podziału na
prowadzącego/słuchających nie ma, albo nie jest ścisły - zainspirowała
mnie forma Agile Warsaw. Dlatego wolę jakieś małe sale gdzie wszyscy
mogą siedzieć obok siebie - a nie w ławach na auli jak na MIMUW. To
nie znaczy, że jak ktoś chciałby się podzielić swoim nowym odkryciem,
które właśnie bada, albo pochwalić/pożalić jak to się robi u niego na
co dzień to nie będzie super. Będzie! Zapraszamy! Może tematycznie, na
liście ustalimy problemy z najczęściej występują i może zrobimy
spotkanie na którym 3, 4 osoby opowiedzą po 20min jak to się u nich
rozwiązuje i później / w trakcie dyskusja.
Ciekawą opcją mógłby też być książkowy klub dyskusyjny - czytamy
wcześniej ustalony rozdział z książki (np. DDD) a później na spotkaniu
możemy przedyskutować wnioski.
Zainteresowani?
--
Pozdrawiam
Piotr Przybylak
Wojciech Erbetowski
I'm in!
Możemy jechać przykład ze sklepem, później zrobimy z niego np.:
czołowego dostawce książek na rynke Polski ;)
Z obsługą magazynu, statusami dostaw, integracją z firmą kurierską etc
Czytanie po jednym rozdziale jest fajnym pomysłem i forma CodeRetreat
też wydaje się pasować idealnie.
Marek
2012/1/1 Piotr Przybylak <piotr.p...@gmail.com>:
--
Marek Kirejczyk
marek.k...@gmail.com
Jakub Nabrdalik
Pragmatist?
Np. TouK? Aenima? Moglibyśmy rotować miejsce, żeby nikt nie był
pokrzywdzony.
W dniu 02.01.2012 11:09, Wojciech Erbetowski pisze:
> Takie wieczorki literackie nam się zrobią :-)
>
> Bomba pomysł, ja też się piszę :-)
>
> W dniu 2 stycznia 2012 11:06 użytkownik Marek Kirejczyk
> <marek.k...@gmail.com <mailto:marek.k...@gmail.com>> napisał:
>
> I'm in!
>
> Możemy jechać przykład ze sklepem, później zrobimy z niego np.:
> czołowego dostawce książek na rynke Polski ;)
> Z obsługą magazynu, statusami dostaw, integracją z firmą kurierską etc
>
> Czytanie po jednym rozdziale jest fajnym pomysłem i forma CodeRetreat
> też wydaje się pasować idealnie.
>
> Marek
>
>
> 2012/1/1 Piotr Przybylak <piotr.p...@gmail.com
> <mailto:piotr.p...@gmail.com>>:
> marek.k...@gmail.com <mailto:marek.k...@gmail.com>
Artur Gajowy
W dniu niedziela, 1 stycznia 2012, 23:25:13 UTC+1 użytkownik Piotr napisał:
Myślę że najbardziej produktywne będą dyskusje przy odpalonym IDE
gdzie albo będziemy wspólnie kodowali, albo ktoś będzie pokazywał na
konkretnym kodzie rozwiązanie które stosuje albo pomysł który chciałby
wypróbować.
Alternatywnie na spotkaniach moglibyśmy też analizować dostępne w
sieci przykłady dla różnych stylów architektonicznych,
jak chociażby ddd-cqrs-sample Sławka Sobótki
http://code.google.com/p/ddd-cqrs-sample/source/checkoutczy przykładowy system z książki Growing Object-Oriented Software
Guided by Tests
http://www.growing-object-oriented-software.com/code.html
(...)
Ciekawą opcją mógłby też być książkowy klub dyskusyjny - czytamy
wcześniej ustalony rozdział z książki (np. DDD) a później na spotkaniu
możemy przedyskutować wnioski.
Zainteresowani?
Marek Kirejczyk
bez pełnej implementacji.
2012/1/2 Artur Gajowy <artur...@gmail.com>:
--
Marek Kirejczyk
marek.k...@gmail.com
Filip Matuszewski
Marcin Zajączkowski
> To może, zachowując kameralną atmosferę, trochę bliżej centrum niż
> Pragmatist?
>
> Np. TouK? Aenima? Moglibyśmy rotować miejsce, żeby nikt nie był
> pokrzywdzony.
Dla mnie Pragmatists jest ok, ale nie będę wybrzydzał w innych
"kameralnych" miejscach, jeżeli takowe się znajdę.
Btw, polemizowałbym, czy Touk logistycznie jest tak dużo bliżej centrum
niż Pragmatists :)
Marcin
--
http://blog.solidsoft.info/ - Working code is not enough
Jakub Nabrdalik
> Btw, polemizowałbym, czy Touk logistycznie jest tak dużo bliżej centrum
> niż Pragmatists :)
Jedno jest pewne. W korkach podróż z TouK do Pragmatist (i w drugą
stronę) komunikacją miejską to 1:30h. Dobrze, że w końcu zrobiłem
prawko. Ma ktoś tani samochód do sprzedania?
Marcin Zajączkowski
> W dniu 2012-01-03 00:02, Marcin Zajączkowski pisze:
>> Btw, polemizowałbym, czy Touk logistycznie jest tak dużo bliżej centrum
>> niż Pragmatists :)
>
> Jedno jest pewne. W korkach podróż z TouK do Pragmatist (i w drugą
> stronę) komunikacją miejską to 1:30h. Dobrze, że w końcu zrobiłem
> prawko. Ma ktoś tani samochód do sprzedania?
Autem to pewnie będzie przynajmniej tyle samo, a tylko się nadenerwujesz
i nic nie poczytasz w tym czasie :).
Na pewno plusem Aeminy jest, że można szybciutko pieszo od metra/z
centrum tam dojść.
Marcin
Piotr Przybylak
https://bitbucket.org/piotrp/architects-wannabe/
Jak ktoś ma ochotę zrobić wersję CQRS/DCI/CDI/Hexagon albo nawet
alternatywną classic to zapraszam do forkowania. Oczywiście jesteśmy
otwarci na różne języki programowania :D
Pozdro
Piotrek
W dniu 3 stycznia 2012 00:54 użytkownik Marcin Zajączkowski
<msz...@wp.pl> napisał:
--
Pozdrawiam
Piotr Przybylak
Piotr Przybylak
<michal.gr...@gmail.com> napisał:
>
> Na początek mam uwagę odnośnie formy spotkania. Bardzo mi się podoba
> pomysł, żeby oglądać jakąś prezentację, a potem dyskutować. To może
> być najlepsza forma jak dla tej grupy. Jednak uważam, że znacznie
> lepiej byłoby poprosić o obejrzenie prezentacji przed spotkaniem.
> Spotkanie można byłoby wtedy wykorzystać na dyskusję. A tak,
> spotkaliśmy się żeby posiedzieć przed rzutnikiem, za to na dyskusję
> było mało czasu.
Mój zamysł był taki, żeby przeszkodą w organizowaniu spotkań nie stał
się brak prelegentów/prowadzących, którzy musieliby odrobić "pracę
domową" i coś przygotować przed spotkaniem.
Tak samo nie chciałem, żeby uczestnicy musieli odrabiać jakąś pracę
domową przed przyjściem na spotkanie - mnie by to wkurzało ;>
A tak - przyjście na spotkanie to sam relaks all inclusive ;>
Opcja z oglądaniem wcześniej też jest interesująca dlatego od razu
przy zaproszeniu na spotkanie podałem linka do prezentacji. Ja na
przykład wolę obejrzeć wcześniej żeby na spokojnie się zapoznać z
tematem jak napisałeś i ew. przemyśleć doczytać itp a później i tak
chętnie oglądam jeszcze raz razem z wszystkimi żeby sobie "wspólny
kontekst" zbudować ;>
A może mieć ciastko i zjeść ciastko ?
Na 18 wielu osobom może być ciężko dotrzeć. Na przykład Agile Warsaw
jest zazwyczaj o 18.57 i jakoś udaje się wcisnąć i prezkę i dyskusję i
upadlanie się alkoholem.
Może róbmy start filmu o 18 a start dyskusji o 19 ?
Ewentualnie proponuję (i zaraz zrobię na to oddzielny wątek) zgłaszać
prezentacje które już się obejrzało z jej oceną + opcjonalnie ktrótkim
podsumowanie.
Później możemy się spotkać aby przedyskutować tę naj.. bardziej
popularną/wyjżej ocenianą/większe kontrowersje budzącą.
--
Pozdrawiam
Piotr Przybylak