WSAG #4
Wydarzenie publiczne

Organizator: WSAG (Warsaw Software Architecture Group)
145 Puławska
wtorek, 21 kwietnia 2026, 18:00
Zakończenie: wtorek, 21 kwietnia 2026 21:00

Lokalizacja
145 Puławska
Data i czas
wtorek, 21 kwietnia 2026, 18:00
Zakończenie: wtorek, 21 kwietnia 2026 21:00
O tym wydarzeniu
Czwarte spotkanie: 21 Kwietnia, 18.00, biuro Circle K Warszawa, Puławska 145 (mapa/pinezka, przy samym metrze Wilanowska)
3️⃣ prezentacje w agendzie:
👉 Artur Wojnar: Software Architecture: The Bad Parts
In this talk, I will demonstrate how so-called good practices combined with a shallow understanding of the domain can create a dangerous illusion of control.
Using a real-world example from the Connected Health domain—specifically, liver cancer risk alerting—I will show how a noun-driven design approach leads to excessive coupling and brittle systems.
The talk will explore common architectural pitfalls such as context violations, database coupling, domain leakage, and mixing read and write models. I will also challenge a popular industry belief by explaining why Clean/Hexagonal Architecture is not an architecture.
Attendees will leave with a clearer understanding of how design decisions shape system behavior—and how easily “best practices” can fail when the domain is misunderstood.
👉 Jacek Milewski: How We Waste Time Building APIs — and the Moment DDD Starts to Matter
Is Domain-Driven Design just a theoretical concept?
When working in the trenches, most teams don’t start with Bounded Contexts or Context Maps. They start with tickets, acceptance criteria, and... the need to ship APIs!
Over time, APIs grow. New consumers appear. Shared resources emerge. And suddenly teams struggle with questions like:
- Who owns this API?
- Can we change this contract?
- Why does every small decision require an architect?
In this talk, I’ll tell the story of how teams naturally evolve APIs in chaos — and why this is not a failure.
I’ll show the moment when Domain-Driven Design stops being theoretical and becomes a practical decision-making tool: helping teams reason about relationships between bounded contexts, ownership, and autonomy — without “doing full DDD”.
This is not a tutorial. It’s a provocative look at how strategic DDD can support evolutionary API design and team autonomy in large systems.
👉 Maciej Jedrzejewski: Blizny zamiast Certyfikatów
Ż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.