DevTalk Menu

Viewing all items for tag mikroserwisy

Permalink:

DevTalk Trio S04E04 – Jak wyznaczać granice agregatów w DDD?

(comments are closed)

Agregat to chyba najczęściej źle rozumiany wzorzec taktyczny w DDD.

I znowu o tych agregatach, i znowu o tym DDD… no właśnie znowu, bo gdyby były projektowane dobrze, nie musielibyśmy do tego wracać.

Z tego odcinka dowiesz się:

  • Czym naprawdę jest agregat;
  • Dlaczego modelowanie „jak wygląda świat rzeczywisty” prowadzi na manowce;
  • Czy „atom” byłby uczciwszą nazwą niż „agregat”;
  • Czy współbieżność i rywalizacja o zasoby wywracają definicję z 2003;
  • Jak właściwa granica wyłania się z czasowników, nie z rzeczowników;
  • Kiedy agregatu w ogóle nie ma;
  • Czym jest agregat procesowy i jak wiąże się z sagami i granicami mikroserwisów.

 

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 S04E02 – Metryki granic i modeli

(comments are closed)

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 #142 – O systemach rozproszonych w dobie AI z Grzegorzem Piwowarkiem

(comments are closed)

Odcinek to gęsta, techniczna rozmowa z Grzegorzem Piwowarkiem: niezależnym specjalistą od architektur backendowych i systemów rozproszonych. Grzesiek to praktyk z krwi i kości, który specjalizuje się w systemach, gdzie wymagania niefunkcjonalne mają znaczenie i gdzie przy dużym ruchu regularnie dzieją się rzeczy, które „nie powinny się zdarzać”.

Z tego odcinka dowiesz się:

  • Czym są systemy rozproszone i skąd się wzięły;
  • Co to jest idempotencja;
  • Czym są rozproszone transakcje i wzorzec Saga;
  • Jak uniknąć sytuacji, gdzie lot jest zaklepany, ale taksówki już nie ma;
  • Czym jest zegar logiczny i kiedy go stosować;
  • Gdzie LLM-y sobie radzą, a gdzie ewidentnie nie.

 

Ponadto Grzesiek dzieli się też konkretną historią z produkcji — i tym, gdzie LLM zaproponował rozwiązanie gorsze niż sam problem.

 

A teraz… PLAY!

Czytaj dalej…

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