Dzisiaj coś dla miłośników Enterprise Edition.
Nieustannie rozwijamy projekt ilustrujący implementację zaawansowanych technik Domain Driven Design i architektury Command-query Responsibility Segregation.
Dotychczasowa implementacja oparta na Springu doczekała się swego lustrzanego odbicia na platformie Java EE6
W projekcie znajdziecie między innymi kilka sztuczek w CDI oraz przykłady wykorzystania silnika zdarzeń w modelowaniu biznesowym (dowiecie się również dlaczego budowany Events<> jest nieco ułomny:).
Więcej szczegółów na blogu projektu.
//===========================
W najbliższych planach aplikacja kliencka na Androidzie w architekturze Eventually Connected Client.
środa, 14 grudnia 2011
środa, 30 listopada 2011
Geneza boskich klas
Zarówno po dzisiejszej konferencji softdevcon jak i zeszłotygodniowej JDD kilka osób prosiło mnie o powtórzenie tekstu o "boskich klasach", którym staram się rozbudzić uczestników prezentacji o DDD. Postanowiłem nieco rozszerzyć opowiastkę...
Poczynania śmiałka powodują oczywiście niejednokrotnie lawiny, które rozrywają na dole i tak już nieszczelne siatki bezpieczeństwa testów.
Boska klasa aby istnieć potrzebuje ofiar. Najlepsze są młode, niewinne praktykantki. W swej naiwności opartej na akademickich wierzeniach we wszechmoc Maszyny Turinga składają się w ofierze na ołtarzu Boskiej Klasy...
Z czasem udaje im się wyrwać z grawitacji osobliwości, ale już nigdy nie będą takie jak wcześniej...
Narodziny
Każda boska klasa ma swój początek jako niewinny ośmiotysięcznik - klasa zawierająca osiem tysięcy linijek kodu.
Eskalacja
Zmiany w ośmiotysięczniku wymagają specjalnej wyprawy. Śmiałek wspina się przez kilka dni na wysokość ok piątego tysiąca próbując zrozumieć logikę/ironię kodu po czym zakłada tam bazę - rozgrzebuje kod kilkoma enterami aby zrobić sobie nieco miejsca, w którym to następnego dnia (bo aktualnie opada z wycieńczenia i niedoboru podstawowych neuroprzekaźników w mózgu) zacznie drążyć tunelik jako fundament dla nadbudówek.Poczynania śmiałka powodują oczywiście niejednokrotnie lawiny, które rozrywają na dole i tak już nieszczelne siatki bezpieczeństwa testów.
Kolaps
Z czasem ośmiotysięcznik rozrasta się aby w końcu zapaść się grawitacyjnie pod własnym ciężarem. Powstaje wówczas osobliwość, z której wyłania się Boska Klasa - klasa, która wszystko wie, wszystko potrafi i jest połączona ze wszystkim w każdym możliwym wymiarze.Boska klasa aby istnieć potrzebuje ofiar. Najlepsze są młode, niewinne praktykantki. W swej naiwności opartej na akademickich wierzeniach we wszechmoc Maszyny Turinga składają się w ofierze na ołtarzu Boskiej Klasy...
Z czasem udaje im się wyrwać z grawitacji osobliwości, ale już nigdy nie będą takie jak wcześniej...
wtorek, 1 listopada 2011
DDD must read
Od dłuższego czasu nosiłem się z zamiarem napisania posta poświęconego modelowaniu agregatów - różnym podejściom i wynikającym z nich konsekwencjom.
Właściwie temat nie jest związany ze specyfiką DDD, a ogólnie z modelowaniem obiektów biznesowych z zachowaniem ich enkapsulacji, które dzięki niej są bardziej odporne na zmiany.
Skoro jednak w sieci istnieją już materiały z dobrą ilustracją graficzną oraz przykładami w kodzie, to oszczędzę sobie pisania i pozwolę polecić ich lekturę każdemu kto zajmuje się modelowanie lub projektowaniem obiektowym (heh kto z czytelników się nie zajmuje "przy okazji" innych spraw?):
//============================
Tak jak pisałem wcześniej tematyka jest ogólna, nie związana stricte z DDD i lektura powinna być pożyteczna dla każdego.
Właściwie temat nie jest związany ze specyfiką DDD, a ogólnie z modelowaniem obiektów biznesowych z zachowaniem ich enkapsulacji, które dzięki niej są bardziej odporne na zmiany.
Skoro jednak w sieci istnieją już materiały z dobrą ilustracją graficzną oraz przykładami w kodzie, to oszczędzę sobie pisania i pozwolę polecić ich lekturę każdemu kto zajmuje się modelowanie lub projektowaniem obiektowym (heh kto z czytelników się nie zajmuje "przy okazji" innych spraw?):
//============================
Tak jak pisałem wcześniej tematyka jest ogólna, nie związana stricte z DDD i lektura powinna być pożyteczna dla każdego.
niedziela, 9 października 2011
Konferencja Warsjawa - kolejny warsztat DDD&CqRS Leaven
Zapraszam na konferencję Warsjawa, która odbędzie się w najbliższą sobotę (15 października) w Warszawie.
Warto dodać, że konferencja jest całkowicie darmowa:)
Podczas konferencji będziecie mogli uczestniczyć między innymi w naszych warsztatach, poświęconych projektowi DDD&CqRS Leaven.
Szczegółowy program warsztatów: https://github.com/warszawajug/warsjawa2011/wiki/Warsztaty-DDD-i-CqRS.
Warto dodać, że konferencja jest całkowicie darmowa:)
Podczas konferencji będziecie mogli uczestniczyć między innymi w naszych warsztatach, poświęconych projektowi DDD&CqRS Leaven.
Szczegółowy program warsztatów: https://github.com/warszawajug/warsjawa2011/wiki/Warsztaty-DDD-i-CqRS.
środa, 5 października 2011
Persystentny Multi-Listener, czyli... Saga
Persystentny multi-listener... jak to pięknie brzmi...:)
Cóż to takiego?
Listener - czy obiekt słuchający zdarzeń,
mulit - czyli chodzi o wiele zdarzeń,
persystentny - czyli posiadający trwały stan.
Podczas ostatnich warsztatów z zakresu projektu DDD-CqRS Leaven wspomniana wyżej technika modelowania czasu spotkała się z zainteresowaniem wielu osób. Nic dziwnego, jest to dosyć nowy pattern; również na szkoleniach wzbudza zawsze największe emocje. Głównie dlatego, że ciężko pogodzić się z myślą, że coś tak złożonego można modelować i implementować w tak prosty i przyjemny sposób:P
Pattern ma swoją oficjalną nazwę, brzmi ona Saga. Jeżeli saga kojarzy się senior developerom z sagą rodziny Carringtonów, to dobrze się Wam kojarzy. Saga to coś co może rozciągać się w czasie niczym telenowela. Saga jest patternem służącym do orkiestracji wielu zdarzeń, które mogą zajść w rozproszonym systemie w nieokreślonej kolejności. Czas pomiędzy zajściem zdarzeń może być relatywnie długi, dlatego należy persystować jej stan w czasie oczekiwania na kolejne zdarzenie.
Przykład:
Wyobraźmy sobie system, w którym mamy moduły: sprzedaży, płatności i magazynu.
W module sprzedaży możemy zatwierdzić obiekt biznesowy Zamówienie. Zamówienie rzuca wówczas zdarzenie biznesowe ZatwierdzonoMnie zawierające id tegoż zamówienia.
W module płatności możemy dokonać wpłaty. Być może jest to przedpłata dokonana wcześniej niż zatwierdzenie zamówienia... Moduł ten rzuca zdarzenie niosące informację o zajściu faktu dokonania wpłaty.
Oba zdarzenia są orkiestrowane przez sagę Zakupy. Jeżeli otrzyma ona oba zdarzenia (pasujące po id biznesowym) i stwierdzi, że jesteśmy "kwita" wówczas może wysłać sygnał do modułu magazynowego aby przygotować paczkę do wysyłki.
Oczywiście możemy tego typu proces zaimplementować w inny sposób niż zdarzeniowy, ale jeżeli zależy nam na decouplingu modułów systemu (wraz z wszystkimi konsekwencjami: skalowanie, testowanie, rozszerzalność, otwartość na dodawanie pluginów, redukcja architektury Speaghetti na poziomie modułów) to warto posłużyć się Sagą.
Udi Dahan dosyć dobrze wyjaśnia motywację oraz szczegóły koncepcyjne: Saga Persistence and Event-Driven Architectures dlatego nie chcę powtarzać, tego co zostało napisane ponad 2 lata temu.
Jak widać w powyższym linku technicznie Saga to złożenie 2 wzorców: Observer i Memento. O ile observera każdy zna choćby z bibliotek graficznych i wszechobecnych tam onClickListenerów, o tyle Memento jest mniej znanym patternem. Jeżeli ktoś oglądał film pt. Memento o człowieku, który miał problem z transferem danych z pamięci podręcznej (kora przed-czołowa) do pamięci długotrwałej (hipokamp) to skojarzenie jest również poprawne. Memento to pattern służący obiektom na wysyłanie do siebie informacji na przyszłość. Tak jak bohater filmu, który zapisywał i tatuował sobie na rękach informacje o tym co należy zrobić w przyszłości:)
Natomiast zainteresowanych szczegółami implementacji Sagi odsyłam do przykładu w projekcie DDD&CqRS Leaven:
//=============================================
Jako ciekawostkę dodam, że niektóre szyny komunikatów w .NET wspierają mechanizm Sagi niejako "z pudełka"...
Techniczny komunikat (message) jest traktowany na poziomie logicznym jak zdarzenie (event). Ichnie "Message Driven Beany" reagaujące na wiele zdarzeń to po prostu Sagi. Do tego automatyczne ładowanie i zapisywanie Memento, kończenie albo usypianie sagi oraz drobny szczegół: obsługa współbieżności...
Natomiast my w swym świecie Javy wciąż szukamy uber-frameworka webowego, który daje złudzenie, że każdy system jest CRUDem...
Cóż to takiego?
Listener - czy obiekt słuchający zdarzeń,
mulit - czyli chodzi o wiele zdarzeń,
persystentny - czyli posiadający trwały stan.
Podczas ostatnich warsztatów z zakresu projektu DDD-CqRS Leaven wspomniana wyżej technika modelowania czasu spotkała się z zainteresowaniem wielu osób. Nic dziwnego, jest to dosyć nowy pattern; również na szkoleniach wzbudza zawsze największe emocje. Głównie dlatego, że ciężko pogodzić się z myślą, że coś tak złożonego można modelować i implementować w tak prosty i przyjemny sposób:P
Pattern ma swoją oficjalną nazwę, brzmi ona Saga. Jeżeli saga kojarzy się senior developerom z sagą rodziny Carringtonów, to dobrze się Wam kojarzy. Saga to coś co może rozciągać się w czasie niczym telenowela. Saga jest patternem służącym do orkiestracji wielu zdarzeń, które mogą zajść w rozproszonym systemie w nieokreślonej kolejności. Czas pomiędzy zajściem zdarzeń może być relatywnie długi, dlatego należy persystować jej stan w czasie oczekiwania na kolejne zdarzenie.
Przykład:
Wyobraźmy sobie system, w którym mamy moduły: sprzedaży, płatności i magazynu.
W module sprzedaży możemy zatwierdzić obiekt biznesowy Zamówienie. Zamówienie rzuca wówczas zdarzenie biznesowe ZatwierdzonoMnie zawierające id tegoż zamówienia.
W module płatności możemy dokonać wpłaty. Być może jest to przedpłata dokonana wcześniej niż zatwierdzenie zamówienia... Moduł ten rzuca zdarzenie niosące informację o zajściu faktu dokonania wpłaty.
Oba zdarzenia są orkiestrowane przez sagę Zakupy. Jeżeli otrzyma ona oba zdarzenia (pasujące po id biznesowym) i stwierdzi, że jesteśmy "kwita" wówczas może wysłać sygnał do modułu magazynowego aby przygotować paczkę do wysyłki.
Oczywiście możemy tego typu proces zaimplementować w inny sposób niż zdarzeniowy, ale jeżeli zależy nam na decouplingu modułów systemu (wraz z wszystkimi konsekwencjami: skalowanie, testowanie, rozszerzalność, otwartość na dodawanie pluginów, redukcja architektury Speaghetti na poziomie modułów) to warto posłużyć się Sagą.
Udi Dahan dosyć dobrze wyjaśnia motywację oraz szczegóły koncepcyjne: Saga Persistence and Event-Driven Architectures dlatego nie chcę powtarzać, tego co zostało napisane ponad 2 lata temu.
Jak widać w powyższym linku technicznie Saga to złożenie 2 wzorców: Observer i Memento. O ile observera każdy zna choćby z bibliotek graficznych i wszechobecnych tam onClickListenerów, o tyle Memento jest mniej znanym patternem. Jeżeli ktoś oglądał film pt. Memento o człowieku, który miał problem z transferem danych z pamięci podręcznej (kora przed-czołowa) do pamięci długotrwałej (hipokamp) to skojarzenie jest również poprawne. Memento to pattern służący obiektom na wysyłanie do siebie informacji na przyszłość. Tak jak bohater filmu, który zapisywał i tatuował sobie na rękach informacje o tym co należy zrobić w przyszłości:)
Natomiast zainteresowanych szczegółami implementacji Sagi odsyłam do przykładu w projekcie DDD&CqRS Leaven:
- opis: http://code.google.com/p/ddd-cqrs-sample/wiki/DomainDrivenDesignBusinessDeveloperMentalModel#Saga
- kod os strony programisty biznesowego: http://code.google.com/p/ddd-cqrs-sample/source/browse/#svn%2Ftrunk%2Fddd_cqrs-sample%2Fsrc%2Fmain%2Fjava%2Fpl%2Fcom%2Fbottega%2Ferp%2Fsales%2Fsaga
- idea i implementacja silnika Sagi:http://code.google.com/p/ddd-cqrs-sample/wiki/CommandQueryResponsibilitySegregationSystemArchitectMentaModel#Saga_Engine
//=============================================
Jako ciekawostkę dodam, że niektóre szyny komunikatów w .NET wspierają mechanizm Sagi niejako "z pudełka"...
Techniczny komunikat (message) jest traktowany na poziomie logicznym jak zdarzenie (event). Ichnie "Message Driven Beany" reagaujące na wiele zdarzeń to po prostu Sagi. Do tego automatyczne ładowanie i zapisywanie Memento, kończenie albo usypianie sagi oraz drobny szczegół: obsługa współbieżności...
Natomiast my w swym świecie Javy wciąż szukamy uber-frameworka webowego, który daje złudzenie, że każdy system jest CRUDem...
poniedziałek, 3 października 2011
środa, 28 września 2011
Zapraszamy na warsztaty z "wypiekania zaczynu" (DDD, BDD, CqRS)
W najbliższą sobotę (1 października) organizujemy w ramach lubelskiego JUGa otwarte warsztaty z zakresu:
- modelowania z wykorzystaniem Domain Driven Design
- procesu Behavior Driven Development (w tym wykorzystanie JBehave, Selenium i Agentów)
- architektury Command-query Responsibility Segregation
Warsztaty będą przeprowadzone na podstawie materiałów z otwartego i darmowego projektu DDD+CqRS Leaven.
Szczegóły wydarzenia na stronie JUGa.
//============================
Dla zainteresowanych z innych zakątków Polski informacja: planujemy tego typu inicjatywy podczas zbliżających się konferencji branżowych - szczegóły wkrótce.
- modelowania z wykorzystaniem Domain Driven Design
- procesu Behavior Driven Development (w tym wykorzystanie JBehave, Selenium i Agentów)
- architektury Command-query Responsibility Segregation
Warsztaty będą przeprowadzone na podstawie materiałów z otwartego i darmowego projektu DDD+CqRS Leaven.
Szczegóły wydarzenia na stronie JUGa.
//============================
Dla zainteresowanych z innych zakątków Polski informacja: planujemy tego typu inicjatywy podczas zbliżających się konferencji branżowych - szczegóły wkrótce.
Subskrybuj:
Posty (Atom)