DevTalk Menu

Viewing all items for tag architektura oprogramowania

Permalink:

DevTalk Trio S04E02 – Metryki granic i modeli

Skąd wiesz, że Twój podział na moduły i konteksty w DDD jest dobry? Zamiast polegać na intuicji, pokazujemy konkretne metryki oceny architektury: rozwijalność, autonomię zespołów i mierzenie zależności między modułami na poziomie strategicznym i taktycznym.

Z tego odcinka dowiesz się:

  • Ile poziomów wiedzy o metrykach naprawdę istnieje;
  • Dlaczego rozwijalność mówi więcej niż wszystko inne;
  • Jak symulować przyszłe zmiany, zanim nadejdą;
  • Czym są antywymagania i po co je stawiać;
  • Jak policzyć zależności (strzałki) między modułami;
  • Dlaczego dobro biznesu bywa wymówką;
  • Kiedy metryka rozwijalności przestaje działać;
  • Czym grozi joinowanie po mikroserwisach;
  • Dlaczego autonomia to nie cel, tylko środek;
  • Po co robić cztery alternatywne modele naraz;
  • Czym jest second system syndrome.

 

 

A teraz… PLAY!

Czytaj dalej…

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

DevTalk Trio S04E01 – Czym jest ten przeklęty Bounded Context i czy w 2026 go potrzebujesz?

(comments are closed)

Czy Bounded Context po ponad dwóch dekadach jeszcze się broni?

Jakub Pilimon, Ignacy Szreter i Sławek Sobótka uczyli się Domain-Driven Design w trzech różnych epokach (od monolitów, na których wieczorami grało się w Quake’a, po dzisiejszy świat SaaS-ów) i swoim doświadczeniem dzielą się w tym odcinku DevTalk.

Z tego odcinka dowiesz się:

  • Skąd wziął się bounded context u Evansa;
  • Kiedy analiza lingwistyczna pomaga, a kiedy zawodzi;
  • Czy kilka zespołów może pracować na jednym kontekście;
  • Jak jedna technika stała się nazwą dyscypliny;
  • Dlaczego jeden „pacjent” to tak naprawdę kilka różnych rzeczy;
  • Czym jest autonomiczny model i po co go stosujemy;
  • Czego o modelowaniu uczy crash test samochodu;
  • Jak zmienił się świat od monolitów do SaaS-ów;
  • Dlaczego to IT najlepiej rozumie biznes.

 

A teraz… PLAY!

Czytaj dalej…

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

DevTalk #146 – O outbox i spektrum wzorców “at least once” z Jackiem Milewskim

(comments are closed)

W tej rozmowie wracamy do fundamentów, bez których żaden rozproszony system nie działa jak należy: do komunikacji między serwisami.

Jacek Milewski prowadzi nas przez całe spektrum wzorców dostarczania wiadomości. Zaczniemy od naiwnych (synchroniczny fire-and-forget, prosty async), przez ogarnięte (transakcyjny Outbox, Inbox, Optimistic Outbox), aż po poziom PRO (shared kernel, Change Data Capture, Consumer Driven Redelivery, listen to yourself).

Każdy wzorzec to nie wybór między dobrem a złem, tylko świadomy trade-off: który zestaw problemów wolimy w przyszłości rozwiązywać.

Z tego odcinka dowiesz się:

  • Dlaczego już przy jednym mikroserwisie masz do czynienia z systemem rozproszonym;
  • Czym różni się at most once i at least once;
  • Kiedy naiwny wzorzec fire-and-forget jest w pełni rozsądnym wyborem;
  • Na czym polega transakcyjny Outbox;
  • Jak działać z Inboxem, deduplikacją i emulowaniem kolejności po stronie odbiorcy;
  • Czym jest idempotentność;
  • Dlaczego retry potrafi położyć system, zamiast go uratować;
  • Kiedy sięgnąć po shared kernel, CDC i Consumer Driven Redelivery — i za jaką cenę.

 

A teraz… PLAY!

Czytaj dalej…

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

DevTalk Trio S03E07 – Taktyczne wzorce projektowe vs. LLM

(comments are closed)

Jakub Kubryński, Łukasz Szydło i Kuba Pilimon w kolejnym odcinku DevTalk Trio! Dziś rozmawiają o tym, dlaczego faza projektowania to wciąż domena człowieka i jak mądrze używać LLM-ów, żeby nie produkować pięknie wyglądającego, ale bezużytecznego kodu.

Niby szeroki temat, który przewija się ciągle i wszędzie, ale z tego odcinka dowiesz się:

  • Czy LLM potrafi samodzielnie dobrze zastosować wzorce projektowe;
  • W jaki sposób LLM może pomagać przy modelowaniu domeny;
  • Czy korzystanie z LLM zmniejsza potrzebę modelowania domeny, czy wręcz ją zwiększa;
  • Oraz czy można skompresować wiedzę architekta w skill/prompt i przekazać go mniej doświadczonemu programiście.

 

A teraz… PLAY!

Czytaj dalej…

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.