SALA C
Pełna agenda dnia
10:00
Zmiana pod presją: jak rośnie koszt zmiany i jak go zatrzymać
„Legacy” często kojarzymy z wiekiem i technologią, ale w praktyce kluczowe jest coś innego: koszt zmiany. Pod presją dostarczania rośnie koszt koordynacji, rozmywają się granice odpowiedzialności, a architektura zaczyna odzwierciedlać strukturę komunikacji (prawo Conwaya). Efekt? Coraz większy coupling, coraz mniej przewidywalne wdrożenia i „małe zmiany”, które potrafią wywrócić system. Czy to nieuniknione - czy raczej domyślny skutek presji i braku świadomego projektowania granic?
W mojej prezentacji pokażę, dlaczego koszt zmiany rośnie i jak zatrzymać ten proces dwutorowo. Po pierwsze: jak świadomie projektować granice odpowiedzialności i ograniczać koszt koordynacji, żeby nie hodować sprzężeń. Po drugie: jak pracować z zastanym kodem tak, by koszt zmiany realnie spadał - jak zabezpieczać zachowanie testami, gdzie szukać punktów wpięcia (seams), jak rozcinać zależności i prowadzić refaktoryzację małymi krokami.
Cel jest prosty: sprawić, by każda kolejna zmiana była bezpieczniejsza i tańsza niż poprzednia - nawet w systemie, który dziś „twardnieje” pod presją.
Łukasz Pięta
Java Rockstar
11:00
Przerwa
11:30
Modules: design around processes, not data
Most devs have a data-centric perspective on modularity: they design a system around nouns and data. That is due to 3rd and 5th normal form in relational databases which they still teach you at a University. But here’s the kicker - it’s wrong. We use a higher level language because we implement complex business processes. If we wanted to focus on data, we would be using SQL.
In this talk I’ll give you a set of rules for a module that helps me design enterprise software that is easy to work with, test, change and performs really well. I’ll also show you when it’s safe to break those rules.
The goal is to make your apps “infinitely scalable”, or rather: for the system to never slow you down.
Jakub Nabralik
Java Rockstar
12:30
Przerwa
11:30
Tajemnice konsultanta: archetypy oprogramowania jako fundament architektury, analizy, kodu i... biznesu
DDD nauczyło nas modelować „dosłownie”: wsłuchiwać się w język biznesu, domeny i wiernie odwzorowywać rzeczywistość w kodzie. I to jest dobre… dopóki nie okaże się, że ta dosłowność nie daje nam narzędzia do zauważania problemów, które ktoś już dawno rozwiązał — tylko w innej branży, w innym systemie, w innym czasie. W efekcie zespoły po raz kolejny modelują pozornie różne byty, wymyślają podobne mechanizmy od zera, komplikują granice i tracą szanse nie tylko na ponowne użycie, ale możliwość szybkiego reagowania na zmiany wymagań. A koszt? Najczęściej ponosi biznes - w długim procesie wytwórczym.
W tym wystąpieniu zdradzę swoją tajną broń do projektowania i implementacji dużych systemów biznesowych niwelującą te i inne problemy. Opowiem o archetypach oprogramowania jako brakującym poziomie abstrakcji w projektowaniu systemów, dopełniającym techniki DDD. Wyjaśnię czym są archetypy oprogramowania, czym nie są oraz jak je identyfikować w naszym “specyficznym” biznesie. Podczas tej prezentacji dowiesz się, czy archetypy są dla Ciebie i co mogą Ci dać jeśli jesteś analitykiem, architektem, programistą albo… osobą z biznesu.