No tak… Jakoś ta moja historia dotarła aż dotąd! Pewien czas kodowałem nie rozumiejąc jak skomplikowane to zajęcie… Teraz modeluję ze świadomością jak zmienny jest software oraz jak ładny i bezpieczny może być gdy tylko pragmatycznie podejść doprojektowania, kodowania i testowania. Zadaję pytania aby wyłuskać to co istotne, a odfiltrować szum. Z tego buduję backend, frontend, infrastrukturę i zespół.
Ta droga zaprowadziła mnie też do Bottega IT Minds, gdzie mogę uczyć innych, na najwyższym poziomie, wśród tych od których sam uczyłem się wcześniej. Niewiarygodny fikołek!
Czy DDD to tylko teoria?
Pracując „w okopach”, większość zespołów nie zaczyna od Bounded Contextów ani Context Map.
Zaczyna od ticketów, kryteriów akceptacji i… potrzeby dowiezienia API.
Z czasem API rosną. Pojawiają się nowi konsumenci. Współdzielone zasoby.
I nagle zespoły zaczynają mierzyć się z pytaniami takimi jak:
Kto jest właścicielem tego API?
Czy możemy zmienić ten kontrakt?
Dlaczego każda drobna decyzja wymaga zaangażowania architekta?
W tej prezentacji opowiem historię tego, jak zespoły naturalnie rozwijają API w chaosie — i dlaczego nie jest to porażka.
Pokażę moment, w którym Domain-Driven Design przestaje być teorią, a zaczyna być praktycznym narzędziem podejmowania decyzji: pomagającym rozumieć relacje między bounded contextami, odpowiedzialność i autonomię zespołów — bez „robienia pełnego DDD”.
To nie jest tutorial.
To prowokacyjne spojrzenie na to, jak strategiczne DDD może wspierać ewolucyjny design API i autonomię zespołów w dużych systemach.
