W teleturnieju „Is It Cake?” uczestnicy zgadują, co jest prawdziwym przedmiotem, a co perfekcyjnie udekorowanym ciastem. Test jest prosty — weź nóż i przekrój.

Z architekturą jest podobnie. Vertical Slice Architecture obiecuje niezależne kawałki systemu. Ale czy Twoje slice’y przejdą test noża? Zespoły wdrażają VSA, a ich slice’y wciąż są powiązane przez modele czy Agregaty — developerzy blokują się nawzajem przy każdej zmianie wymagań. Struktura folderów udaje modularność, ale nóż odsłania monolit.

Na tej prezentacji przejdziemy przez konkretną ścieżkę dojrzewania VSA: od slice’ów organizowanych tylko katalogami, przez opracowanie specyfikacji i wydzielenie własnych modeli per slice, aż po w pełni autonomiczne slice’y oparte na Dynamic Consistency Boundary i Event Sourcing’u — gdzie każdy feature można rozwijać, testować i wdrażać niezależnie, bez ryzyka kolizji między programistami czy agentami AI. Zastosujemy w praktyce Domain-Driven Design, Event Modeling i Spec-Driven Development.

Efekt? System, w którym nowa funkcjonalność nie wymaga ciągłych zmian we współdzielonych kawałkach kodu, blokowania się nawzajem i rozwiązywania konfliktów. Krótszy czas dostarczania wartości biznesowej i architektura, która skaluje się wraz z zespołem — nie przeciw niemu.

A co z AI? Sztuczna inteligencja nie zgaduje kontekstu — ona go potrzebuje. Dojrzały slice to idealnie skrojony kontekst i specyfikacja podana na tacy dla Agentów AI.

Przyjdź, jeśli chcesz:

• poznać maturity levels Vertical Slice Architecture i sprawdzić, gdzie jest Twój projekt;
• zobaczyć, jak VSA umożliwia wydajne Spec-Driven Development z produkcyjną jakością;
• zrozumieć, dlaczego „prawdziwy slice” to coś więcej niż folder w projekcie;
• zobaczyć DCB w akcji — slice’y bez zabetonowanych agregatów;
• przestać blokować się nawzajem w zespole przy każdej nowej funkcjonalności;
• w końcu kroić bez strachu.

W teleturnieju „Is It Cake?” uczestnicy zgadują, co jest prawdziwym przedmiotem, a co perfekcyjnie udekorowanym ciastem. Test jest prosty — weź nóż i przekrój.

Z architekturą jest podobnie. Vertical Slice Architecture obiecuje niezależne kawałki systemu. Ale czy Twoje slice’y przejdą test noża? Zespoły wdrażają VSA, a ich slice’y wciąż są powiązane przez modele czy Agregaty — developerzy blokują się nawzajem przy każdej zmianie wymagań. Struktura folderów udaje modularność, ale nóż odsłania monolit.

Na tej prezentacji przejdziemy przez konkretną ścieżkę dojrzewania VSA: od slice’ów organizowanych tylko katalogami, przez wydzielenie własnych modeli per slice, aż po w pełni autonomiczne slice’y oparte na Dynamic Consistency Boundary i Event Sourcing’u — gdzie każdy feature można rozwijać, testować i wdrażać niezależnie, bez ryzyka kolizji między programistami. Zastosujemy w praktyce Domain-Driven Design i Event Modeling.

Efekt? System, w którym nowa funkcjonalność nie wymaga ciągłych zmian we współdzielonych kawałkach kodu, blokowania się nawzajem i rozwiązywania konfliktów. Krótszy czas dostarczania wartości biznesowej i architektura, która skaluje się wraz z zespołem — nie przeciw niemu.

A co z AI? Sztuczna inteligencja nie zgaduje kontekstu — ona go potrzebuje. Dojrzały slice to idealnie skrojony kontekst podany na tacy.

Przyjdź, jeśli chcesz:

• poznać maturity levels Vertical Slice Architecture i sprawdzić, gdzie jest Twój projekt;
• zrozumieć, dlaczego „prawdziwy slice” to coś więcej niż folder w projekcie;
• zobaczyć DCB w akcji — slice’y bez zabetonowanych agregatów;
• przestać blokować się nawzajem w zespole przy każdej nowej funkcjonalności;
• zobaczyć, jak VSA ułatwia współpracę z AI;
• w końcu kroić bez strachu.

⚔ Strudzony skomplikowanym programowaniem herosie! 💪 Poznaj stosowane w realnych projektach praktyki Domain-Driven Design, dzięki analogiom z fantastycznego świata elfów, bohaterów i magii. A to wszystko przyprawione dużą dawką kodu! 🤔 Heroes III to gra strategiczna, dlatego nacisk położymy właśnie na tę (często zaniedbywaną) stronę DDD.

🧠 Przyjdź na tę prezentację, jeśli chcesz:

• dowiedzieć się, jak modularyzacja wpływa na możliwości rozwoju i produktyzację;
• przekładać karteczki z EventStormingu i Event Modelingu 1 do 1 na działający kod;
• poznać sposób na codzienny i szybki rozwój Twoich umiejętności modelowania procesów biznesowych;
• zadbać o wysoką jakość projektu lepszym sposobem niż code review;
• modelować procesy, biorąc pod uwagę różne perspektywy zaangażowanych osób, takie jak: ux/ui, frontend, backend, analityka;
• z odpowiedniej notacji modelu generować testy jednostkowe za pomocą ChatGPT;
• unikać komplikowania kodu bardziej niż modelowany proces biznesowy;
• stosować wzorzec Decider do wyrażania logiki biznesowej w funkcyjnym stylu;
• zaryzykować, że Twoje myślenie zmieni się już na zawsze.

Overview

Mateusz Nowak’s talk at wroclove.rb 2025 presents a practical, technology-agnostic approach to Domain-Driven Design ( DDD) using event modeling and the Heroes of Might and Magic III game as an illustrative domain. He emphasizes learning from domain experts, modeling behavior via events, and translating models directly into code and tests to enable modularity, rapid change, and clearer team collaboration.

Key Points

• Start with domain understanding: obtain knowledge from multiple domain experts in structured workshops. Avoid ad-hoc conversations and database-first design.
• Event Storming to Event Modeling: list domain events (business facts), place them on a timeline, and refine with commands (intentions) and views (read models/UI), deferring technical jargon early.
• Example domain (Heroes III): recruitment flow in dwellings shows availability, price, and hero’s army; events like AvailableCreaturesChanged and CreatureRecruited drive UI updates and system behavior.
• Define boundaries and modules: if events always imply others within a single process, keep them together; if outcomes can arise via different flows (e.g., recruit vs. surrender), separate into modules.
• Use automation (process orchestrator/saga): a small component reacts to events, tracks minimal internal state when needed, and dispatches commands across modules.
• Front-end/back-end contract: views react to events, making data origins explicit and preventing implementation surprises.
• Slice work vertically: mark slices (red/yellow/green), let events be the interface, and enable parallel work ( especially with CQRS where write/read are decoupled).
• Translate model artifacts 1:1 to code: commands, events, and views as immutable data classes, providing clarity and consistency.

Implementation and Testing

• Given-When-Then (GWT) specifications: Given prior events (state), When a command is issued, Then assert resulting events or outcomes.
• Decider pattern with three pure functions:
  • evolve: apply past events to compute current state.
  • decide: validate invariants and return new events based on state and command.
  • react: automation that listens to events and issues commands to other modules.
• Persistence-agnostic: works with event sourcing or traditional persistence (snapshots plus events) without changing core decision logic.
• Early architectural validation reduces later code review overhead; code review becomes a check that implementation matches the agreed model.

Takeaways

• DDD with event modeling fosters shared understanding, modularity, and faster change.
• Model first, code second; let events define boundaries and interfaces.
• Focus quality efforts in planning and modeling to accelerate delivery and reduce rework.

⚔ Strudzony skomplikowanym programowaniem herosie! 💪 Poznaj stosowane w realnych projektach praktyki Domain-Driven Design, dzięki analogiom z fantastycznego świata elfów, bohaterów i magii. A to wszystko przyprawione dużą dawką Kotlina!

🧠 Przyjdź na tę prezentację, jeśli chcesz:

• dowiedzieć się, jak modularyzacja wpływa na możliwości rozwoju i produktyzację;
• przekładać karteczki z EventStormingu i Event Modelingu 1 do 1 na działający kod;
• poznać sposób na codzienny i szybki rozwój Twoich umiejętności modelowania procesów biznesowych;
• zadbać o wysoką jakość projektu lepszym sposobem niż code review;
• modelować procesy, biorąc pod uwagę różne perspektywy zaangażowanych osób, takie jak: ux/ui, frontend, backend, analityka;
• z odpowiedniej notacji modelu generować testy jednostkowe za pomocą ChatGPT;
• unikać komplikowania kodu bardziej niż modelowany proces biznesowy;
• stosować wzorzec Decider do wyrażania logiki biznesowej w funkcyjnym stylu;
• zaryzykować, że Twoje myślenie zmieni się już na zawsze.

⚔ Strudzony skomplikowanym programowaniem herosie! 💪 Poznaj stosowane w realnych projektach praktyki Domain-Driven Design, dzięki analogiom z fantastycznego świata elfów, bohaterów i magii. A to wszystko przyprawione dużą dawką kodu! 🤔 Heroes III to gra strategiczna, dlatego nacisk położymy właśnie na tę (często zaniedbywaną) stronę DDD.

🧠 Przyjdź na tę prezentację, jeśli chcesz:

• dowiedzieć się, jak modularyzacja wpływa na możliwości rozwoju i produktyzację;
• przekładać karteczki z EventStormingu i Event Modelingu 1 do 1 na działający kod;
• poznać sposób na codzienny i szybki rozwój Twoich umiejętności modelowania procesów biznesowych;
• zadbać o wysoką jakość projektu lepszym sposobem niż code review;
• modelować procesy, biorąc pod uwagę różne perspektywy zaangażowanych osób, takie jak: ux/ui, frontend, backend, analityka;
• z odpowiedniej notacji modelu generować testy jednostkowe za pomocą ChatGPT;
• unikać komplikowania kodu bardziej niż modelowany proces biznesowy;
• stosować wzorzec Decider do wyrażania logiki biznesowej w funkcyjnym stylu;
• zaryzykować, że Twoje myślenie zmieni się już na zawsze.

⚔️ Strudzony skomplikowanym programowaniem herosie! 💪 Poznaj stosowane w realnych projektach praktyki Domain-Driven Design, dzięki analogiom z fantastycznego świata elfów, bohaterów i magii. A to wszystko przyprawione dużą dawką Kotlina!

🧠 Przyjdź na tę prezentację, jeśli chcesz:

• dowiedzieć się, jak modularyzacja wpływa na możliwości rozwoju i produktyzację;
• przekładać karteczki z EventStormingu i Event Modelingu 1 do 1 na działający kod;
• poznać sposób na codzienny i szybki rozwój Twoich umiejętności modelowania procesów biznesowych;
• zadbać o wysoką jakość projektu lepszym sposobem niż code review;
• modelować procesy, biorąc pod uwagę różne perspektywy zaangażowanych osób, takie jak: ux/ui, frontend, backend, analityka;
• z odpowiedniej notacji modelu generować testy jednostkowe za pomocą ChatGPT;
• unikać komplikowania kodu bardziej niż modelowany proces biznesowy;
• stosować wzorzec Decider do wyrażania logiki biznesowej w funkcyjnym stylu;
• zaryzykować, że Twoje myślenie zmieni się już na zawsze.

W czasie mojego pierwszego komercyjnego projektu nie umiałem sobie odpowiedzieć na pytanie, co jest najważniejsze w architekturze oprogramowania. Oczywiście można powiedzieć, że „to zależy” i nie minąć się z prawdą. Ale już dzisiaj mam na to swoją osobistą odpowiedź. Wyciągnął ją ode mnie Michał Cwiękała z AnatomiaKodu.pl. Naszą rozmowę o tym, czym jest architektura oprogramowania i skąd się jej uczyć, znajdziesz poniżej. Ponadto dowiesz się:

• Co ma wspólnego komoda w sypialni z architekturą oprogramowania.
• Czy junior powinien uczyć się architektury? A może to wiedza tajemna tylko dla seniorów?
• Kiedy kasa, a kiedy doświadczenie?
• Jak w zrozumieniu architektury pomagają klocki LEGO?
• Gdzie znaleźć źródła do opanowania architektury?

Mówi się, że jedyną stałą w projektach IT jest zmiana. Zmiany wymagań z pewnością nadejdą. To, czy przejdziemy je bezboleśnie, zależy od przygotowania naszego kodu. Kiedy w Polsce mamy 25 stopni, to każdy powie, że jest gorąco. Tę samą temperaturę mieszkaniec Egiptu odczuje jako ochłodzenie. A z pewnością za ciepłą nie uznają jej na Tatooine – planecie o dwóch słońcach. Gdy Polska reprezentacja wychodzi z grupy na Mistrzostwach Świata w piłkę nożną, jest to dla Polaków wielkim świętem. Z drugiej strony dla Niemców może być to po prostu codzienność. 30 stopni, awans do Mistrzostw Świata – to wszystko fakty. Ale od tego, co siedzi w naszych umysłach (a w projektach IT, szczególnie w głowach tzw. biznesu), zależy, jak te fakty zinterpretujemy. W czasie tego webinaru zmierzymy się z tezą, że to właśnie próby zmiany, albo nowej interpretacji, może nie wytrzymać nasz kod. Zobaczymy też, jak przezwyciężyć taki stan rzeczy, korzystając z EventSourcingu oraz mechanizmu projekcji. A to wszystko przy wykorzystaniu bazy danych szytej na miarę naszych celów – EventStore.

Z webinaru z pewnością skorzystają programiści, ale też wszyscy, którzy chcieliby dzięki technologi wyprzedzić konkurencję o kilka lat.

Mówi się, że „Człowiek składa się z sumy swoich doświadczeń”. Co się stanie, jeśli te słowa przełożymy na pisany przez nas software? Nowa aplikacja, no to: Controller, Service, Repository… brzmi znajomo. Ale czy zawsze musi tak być? Jeśli wiesz, czym jest Redux, to zobaczysz, jak podobne rozwiązania wykorzystać na backendzie.

W trakcie spotkania poruszymy powyższe kwestie i przejdziemy przez takie tematy jak:

• zasady SOLID (zobaczymy, że zasada pojedynczej odpowiedzialności, to nie jedynie „metoda, która robi jedną rzecz”);
• Command Query Responsibility Segregation i Domain-Driven Design;
• implementacja Event Sourcingu przy wykorzystaniu TypeScript i frameworka NestJS;
• korzyści biznesowe ze stosowania Event Sourcingu.

Ta prelekcja skierowana jest szczególnie do osób, które nie słyszały wcześniej o Event Sourcing i Command Query Responsibility Segregation. Nie musisz znać TypeScript, a nawet być programistą. Taką wiedzę będzie mógł też wykorzystać Product Owner czy Project Manager. Jeśli po tym spotkaniu w Twojej głowie będą wciąż brzmieć słowa Mistrza Yody („You must unlearn what you have learned”), to znaczy, że osiągnąłeś sukces.

Mówi się, że „Człowiek składa się z sumy swoich doświadczeń”. Co się stanie, jeśli te słowa przełożymy na pisany przez nas software? Nowa aplikacja, no to: Controller, Service, Repository… brzmi znajomo. Ale czy zawsze musi tak być? Jeśli wiesz, czym jest Redux, to zobaczysz, jak podobne rozwiązania wykorzystać na backendzie.

W trakcie spotkania poruszymy powyższe kwestie i przejdziemy przez takie tematy jak:

• zasady SOLID (zobaczymy, że zasada pojedynczej odpowiedzialności, to nie jedynie „metoda, która robi jedną rzecz”);
• Command Query Responsibility Segregation i Domain-Driven Design;
• implementacja Event Sourcingu przy wykorzystaniu TypeScript i frameworka NestJS;
• korzyści biznesowe ze stosowania Event Sourcingu.

Ta prelekcja skierowana jest szczególnie do osób, które nie słyszały wcześniej o Event Sourcing i Command Query Responsibility Segregation. Nie musisz znać TypeScript, a nawet być programistą. Taką wiedzę będzie mógł też wykorzystać Product Owner czy Project Manager. Jeśli po tym spotkaniu w Twojej głowie będą wciąż brzmieć słowa Mistrza Yody („You must unlearn what you have learned”), to znaczy, że osiągnąłeś sukces.

Mówi się, że mężczyźni są z Marsa, a kobiety z Wenus. Niestety stereotypy dochodzą do głosu nie tylko w języku. W świecie humanistek i inżynierów niewiele kobiet decyduje się na kierunki techniczne, a gdy rozpoczynają karierę, zamiast murowanego sukcesu czeka na nie szklany sufit.

Nie zgadzamy się ze status quo. Chcemy wprowadzić zasady fair play i zdyskwalifikować krzywdzące schematy w postrzeganiu kobiet w branży IT. Wiele nas różni, ale na pewno nie predyspozycje zawodowe. Dlatego planujemy zorganizować warsztaty z zakresu programowania i poszukiwania pracy w branży IT dla kobiet w wieku 18–24 lat. Poruszymy tematy, które pomogą młodym programistkom zaplanować i ukształtować karierę

Naszym celem jest pomóc młodym kobietom w odkrywaniu swoich talentów i realizacji marzeń, dodanie im pewności siebie i przekazanie wiedzy i narzędzi, które pozwolą na kontynuowanie nauki po zakończeniu warsztatów.