Wszyscy wiemy, że TDD jest super, tylko dlaczego tak mało z nas stosuje tą metodykę na co dzień? Podczas live codingu postaram się pokazać wam, że życie na fazie może być ciekawe. Oczywiście fazy to - red, green i refactor. Każda faza kojarzy nam się z %integracją%, więc i testy integracyjne się pojawią. Potem postaramy się zostać zaakceptowani przez testy akceptacyjne, a wszystko to będzie sterowane przez TDD. A co z dokumentacją tych wszystkich zdarzeń!? Spokojnie, słyszeliście o Test Driven Documentation?

Dzień za dniem, CRUD za CRUD'em, dni przeciekają między palcami pośród takich samych usług RESTowych. Smutek, zgryzota, szara codzienność. Jedyną radością jest nowa wersja Spring MVC czy też kolejne potyczki pomiędzy obozami RESTafarian. Lecz czasami, raz w życiu, dostajesz w swoje ręce projekt, który budzi Cię do życia. Tym projektem jest "data streaming". I od teraz wszystko co wiesz, całe zdobyte doświadczenie, nie ma już znaczenia.

Hektolitry zdarzeń w binarnym formacie spadają na Twoją głowę jak konfetti. Nagle Twoim problemem zaczyna być opóźnienie w czasach odpowiedzi na poziomie milisekund, rozmiary kolejek i pule wątków. A GC topi kwarc na Twoich procesorach. Głowę zaprzątasz sobie problemami "causal consistency" i "happens beforemilisekund, rozmiarami kolejek i pulami wątków. 

Ta prezentacja to pamiętnik z pola bitwy. Opowieść o RX extensions, Apache Kafka i Hazelcast. Opowieść o tym, kiedy budowanie własnego rozwiązania ma sens. O tym z jakimi problemami się spotkacie, których będziecie starali się unikać jak ognia, a które z nich będziecie musieli rozwiązać sami. Zastanowimy sie też jakie problemy pomożecie rozwiązać biznesowi wykorzystując  strumieniowanie danych. A jeśli jedyne co pozostanie po tej prezentacji w Waszych głowach,  to świadomość, że kolejność zdarzeń ma znaczenie i wiedza na temat tego jak radzić sobie z tym w systemach rozproszonych, wówczas uznam to za sukces.

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.