Event-driven architecture pozwala na obserwowanie, analizowanie oraz dynamiczne reagowanie na wszelkie występujące zdarzenia. 
Większość funkcjonalności naszych aplikacji jest w dużej mierze reakcją na jakieś żądanie czy też sytuację. Dlatego warto poznać zalety przetwarzania zdarzeniowego oraz event-driven architecture. 

Umiejętność rozpoznawania zdarzeń, na które musimy reagować czyni nas bardziej świadomymi domeny, z którą pracujemy. Umieszczanie ich w kodzie sprawia, że nasze aplikacje są spójniejsze, bardziej granularne oraz łatwiejsze w zrozumieniu, rozszerzaniu i modyfikowaniu.

Podczas prezentacji dowiesz się czym jest przetwarzanie zdarzeniowe. Jakie są różnice pomiędzy event processing, a event sourcing. Opowiem o najważniejszych konceptach event-driven architecture oraz o tym, w jaki sposób projektować aplikacje oparte na procesowaniu zdarzeń.

Wyobraźcie sobie startup, w którym liczba osób rośnie z 1 do 100 w ciągu roku a stos technologiczny rozrasta się w podobnym tempie - więcej developerów, więcej narzędzi, więcej usług, więcej środowisk - jak to wszystko ogarnąć, być Agile i przy okazji nie zwariować? Spróbujemy zmierzyć się z tym tematem i poszukać zalet w haśle Infrastructure as Code, odkrywając zalety CI/CD as Code w świecie mikroserwisowego szaleństwa.

Wykład dotyczy głównie wyzwań oraz problemów, które niesie ze sobą dynamicznie rozwijający się startup z punktu widzenia DevOps’owego - luźny stack technologiczny, szybki przyrost pracowników, niekończące się pomysły developerów oraz zmienne wymagania. Wykład poruszy tematy związane z zaletami wynikającymi z utrzymywania infrastruktury w kodzie w rozwiązaniach chmurowych na przykładzie narzędzi takich jak ansible / packer / terraform oraz chmury AWS. Omówiony zostanie również proces CI/CD utrzymywany jako kod na przykładzie Jenkins Pipelines (Groovy DSL) oraz wykorzystania konteneryzacji (docker) w procesach budowania i testowania aplikacji. Zalety tych podejść zostaną przedstawione w kontekście architektury mikroserwisów oraz zmiennych wymagań zarówno biznesowych jak i developerskich.

Tworzenie architektury systemów odpowiadającej przyszłym potrzebom biznesu to wróżenie z fusów. Nie istnieje jedna strategia  na strategiczne planowanie systemu. Zbyt wczesne podjęcie decyzji o architekturze opartej o mikrousługi może utrudnić refaktoryzacje i wprowadzić zbyt dużą bezwładność systemu wyniesioną na poziom infrastruktury i spowolnić development. Z kolei monolit bardzo ciężko opanować.

Zaprezentuję propozycję budowy systemu rozpoczynając od dobrze zorganizowanego monolitu z wyraźnie zaznaczonymi zakresami techniczno-biznesowymi, umożliwiającego podjęcie decyzji w którym kierunku go dekomponować i jak go dostarczać. Jego założeniem będzie dobre wykorzystanie strategicznego i taktycznego Domain-Driven Design, oparcie o Hexagonal Archiecture. Zaprezentuję ciągłe i automatyczne monitorowanie złożoności przypadkowej różnej klasy narzędziami wbudowanymi w CI.

Zapraszam, jeżeli interesuje Cię budowa systemów o bogatej i skomplikowanej domenie biznesowej.