WSAG Meetup #4

W tej prezentacji pokażę, jak tak zwane dobre praktyki w połączeniu z powierzchownym rozumieniem domeny mogą tworzyć niebezpieczną iluzję kontroli. Na podstawie rzeczywistego przykładu z domeny Connected Health — konkretnie alertowania o ryzyku raka wątroby — pokażę, jak podejście noun-driven prowadzi do nadmiernego sprzężenia i kruchych systemów. Omówię typowe pułapki architektoniczne, takie jak naruszenia kontekstu, sprzężenie z bazą danych, wyciek domeny i mieszanie modeli odczytu i zapisu. Podważę też popularne przekonanie branżowe, wyjaśniając, dlaczego Clean/Hexagonal Architecture nie jest architekturą. Uczestnicy wyjdą z głębszym rozumieniem tego, jak decyzje projektowe kształtują zachowanie systemu — i jak łatwo „najlepsze praktyki” mogą zawieść, gdy domena jest źle rozumiana.

Czy Domain-Driven Design to tylko teoretyczna koncepcja? W okopach większość zespołów nie zaczyna od Bounded Contexts czy Context Maps. Zaczyna od ticketów, kryteriów akceptacji i... konieczności dostarczenia API! Z czasem API rosną. Pojawiają się nowi konsumenci. Powstają współdzielone zasoby. I nagle zespoły zmagają się z pytaniami takimi jak: - Kto jest właścicielem tego API? - Czy możemy zmienić ten kontrakt? - Dlaczego każda mała decyzja wymaga architekta? W tej prezentacji opowiem historię o tym, jak zespoły w sposób naturalny rozwijają API w chaosie — i dlaczego nie jest to porażka. Pokażę moment, w którym Domain-Driven Design przestaje być teoretyczny i staje się praktycznym narzędziem do podejmowania decyzji: pomagającym zespołom rozumować o relacjach między bounded contexts, własności i autonomii — bez „robienia pełnego DDD”.

Żaden certyfikat nie nauczy Cię, jak rozmawiać z biznesem, który zmienił zdanie po sześciu miesiącach developmentu. Żadna książka nie opisuje uczucia, kiedy Twoja perfekcyjna architektura rozsypuje się pod pierwszym prawdziwym obciążeniem produkcyjnym. Ta prezentacja to zbiór case'ów, które wydawały się słuszne i okazały się błędem, uporu, który warto było mieć, i kompromisów, które w perspektywie czasu okazały się mądrymi ruchami. Chcę pokazać, że dobry architekt to nie ktoś, kto nie popełnia błędów, ale ktoś, kto buduje sobie wystarczająco dobry katalog porażek, żeby zawczasu rozpoznawać ich wzorce.