[Training] Tactical DDD with Process and Design Level Event Storming (2 days) en

✅ Why Attend This Training?
This workshop is designed for software engineers and technical teams working on complex business domains who want to move from abstract DDD theory to concrete implementation. You'll learn how to bridge the gap between domain analysis and code, using proven collaborative techniques.

This is a practical workshop where participants learn to apply tactical DDD patterns and discover them the Event Storming technique—one of the most effective tools for exploring and modeling domain-driven design (DDD). You will discover how to conduct a successful Event Storming session, identify risks in business processes, and translate workshop outcomes into DDD Building blocks and source code, while adhering to design principles and practices such as Modularity, Communication Patterns, Integration Strategies, Single Point of Failure and Single Point of Truth.

By the end of this course, participants will not only understand how to model rich business domains, but also how to turn these models into scalable, maintainable and testable code using patterns

🧠 Learning Objectives
- Master Process Level and Design Level Event Storming techniques for domain modeling and analysis.
- Understand key tactical Domain-Driven Design (DDD) patterns: Aggregates, Entities, Value Objects, Domain Events, Repositories, Services
- Learn how to write robust, testable code with TDD and a well-structured Test Pyramid

🚀 Key Benefits
- Highly interactive and practical format with real-world scenarios
- Deep understanding of how to translate Event Storming outputs into working code
- Hands-on experience designing Aggregates
- Learn to combine DDD patterns into a cohesive architecture
- Build scalable and maintainable applications supported by a solid testing strategy

👥 Who Should Attend?
- Object-oriented developers (Java, C#) working on domain-rich applications
- Software engineers who want to apply DDD tactical patterns in real-world projects
- Development teams aiming to adopt Event Storming, DDD and TDD

🧰 Prerequisites
- Familiarity with Strategic DDD concepts
- Strong experience with object-oriented programming
- Basic familiarity with application architecture and agile development practices

🔑 Practicalities:
• Level: Advanced
• Duration: 2 days (16h)
• Platform: Java / C#

📚 Agenda – What You’ll Learn and Build
For developers and architects building complex, domain-centric systems

1. 🧱 Foundations of Event Storming
- Get hands-on with the essentials
- What domain events are and how they reveal real business behavior
- Event Storming as a fast, visual tool for cross-functional discovery
🎯 You'll learn to extract meaningful structure from conversations with business experts — and turn ambiguity into clarity.

2. 🧑‍🤝‍🧑 Running Effective Event Storming Sessions
- How to prepare, structure, and facilitate both remote and in-person workshops
- Who to invite — and how to get value from every role
- Differences between Process Level and Design Level sessions
🎯 You’ll gain the confidence to lead sessions that result in concrete design decisions, not just sticky notes.

3. 🧩 Applying Tactical Domain-Driven Design (DDD)
- Aggregates, Entities, Value Objects — when and how to use them
- Domain Services, Repositories, Domain Events — and why they matter
🎯 You'll build up a practical vocabulary for modeling business logic in code, not just on whiteboards.

4. 🗺️ Modeling a Real Domain Together
- Explore a realistic domain scenario
- Define meaningful events, commands, and business policies
🎯 Practice recognizing complexity early — and breaking it down with clear, actionable structure.

5. 🛠️ Connecting Models to Real Architecture
- Introduce Commands, Read Models, Actors, and External Systems
- Make your model executable and scalable
🎯 You’ll learn how to move from domain insight to system design that’s ready for development.

6. 🧮 Designing Aggregates That Scale
- Use Event Storming, Domain Storytelling, and Event Modeling to define Aggregates
- Handle consistency and transactional boundaries in distributed systems
🎯 You’ll design Aggregates that survive real-world pressure and stay maintainable over time.

7. 🧬 Implementing Domain Logic with Confidence
- Data Model vs. Domain Model — avoiding the anemic trap
- Applying Command Query Responsibility Separation (CQRS) for clarity and performance
- Aggregates as state machines using Event Sourcing
🎯 You’ll leave with repeatable patterns to build expressive, future-proof domain logic.

8. 🧪 Testing That Drives Design
- Use the Advanced Test Pyramid to balance fast feedback and confidence
- Apply Test-Driven Development (TDD) to domain behavior
- Write tests based on behaviors, not just methods
🎯 You’ll write tests that shape your design — and protect it from regression and misunderstanding.

[Training] Strategic DDD with Big Picture and Process Level Event Storming (2 days) en

✅ Why Attend This Training?
This workshop is designed for experienced developers, architects, and analysts who work on large-scale, domain-rich systems. It provides hands-on practice with Big Picture and Process Level Event Storming, a visual, collaborative technique that helps teams rapidly explore complex business domains, uncover risks, align stakeholders, and drive architectural decisions.
Participants will learn how to facilitate strategic conversations using domains, ubiquitous language — all foundational patterns in Strategic Domain-Driven Design (DDD) leading to bounded contexts and context maps.

🧠 Learning Objectives
• Master the Big Picture Event Storming technique to analyze existing or new systems
• Learn and apply strategic DDD patterns: Domains, Ubiquitous Language and also Bounded Context, Context Mapping
• Connect business analysis with architectural and organizational design decisions
• Use artifacts from Event Storming sessions to define teams, services, and system boundaries

🚀 Key Benefits
• Practical, step-by-step guidance for facilitating impactful Big Picture and Process Level Event Storming sessions
• Learn how to model and map complex domains collaboratively
• Understand how to make informed architectural and organizational decisions based on strategic patterns
• Develop a shared language across business and tech stakeholders
• Work on a realistic domain scenario — from initial chaos to structured, mapped contexts

👥 Who Should Attend?
• Experienced developers, architects, and technical leads
• Business or systems analysts working with complex domains
• Cross-functional teams seeking to define clear domain boundaries and align architecture with business goals

🧰 Prerequisites
• Understanding of domain analysis and software architecture

🔑 Practicalities:
• Level: Advanced
• Duration: 2 days (16h)

📚 Agenda – What You’ll Learn and Build
For developers, architects, and analysts shaping the strategic structure of software systems

1. 🧱 Understanding the Foundations of Event Storming
• What domain events are and how they help model business behavior
• The Event Storming mindset: exploration through collaboration
🎯 You’ll gain the ability to use Event Storming as a universal discovery language across disciplines.

2. 🧑‍💻 Facilitating a Successful Session
• What’s needed to run a productive session (tools, space, participants)
• In-person vs. online — how to adapt
• The role of the facilitator in guiding exploration
🎯 You'll be equipped to run sessions that produce valuable business and architectural insights.

3. 🗺️ Big Picture Event Storming in Action
• When and why to use Big Picture Event Storming
• Modeling greenfield vs. legacy systems
🎯 You’ll learn how to zoom out and explore the system landscape, aligning your team around a common view.

4. 🧩 Applying Strategic DDD Patterns
• Discovering and using Ubiquitous Language
• Identifying Domains and Ubiquitous Language
• Defining Bounded Contexts and Context Maps to visualize relationships
🎯 You’ll use these patterns to draw clear lines between responsibilities — organizationally and technically.

5. 🎯 Exploring the Domain
• Introduce a realistic business domain scenario
• Apply visual notations and techniques
• Learn Chaotic Exploration and Chronological Structuring
🎯 You’ll practice making sense of messy domains by structuring them step-by-step.

6. 🔍 Defining Bounded Contexts
• Identifying language boundaries and conceptual seams
• Common pitfalls and how to avoid them
🎯 You’ll leave with the ability to define clean, autonomous domains that scale with your organization.

7. 🔄 Designing Cross-Context Communication
• Communication styles and integration patterns between contexts
• Weighing trade-offs: autonomy, coupling, complexity
🎯 You’ll make informed decisions about how services should interact based on strategic clarity.

8. 🧱 From Contexts to Architecture
• Connecting Bounded Contexts to implementation
• Data Model vs. Domain Model — making the right architectural calls
• Mapping contexts to teams, services, and ownership
🎯 You’ll learn how to design systems and teams that reflect the shape of the business — not the org chart.

[Training] Microservice Architecture with DDD and Event Storming (4 days) en

✅ Why Attend This Training?
This advanced workshop is dedicated to designing robust microservice-based systems using Domain-Driven Design (DDD) and Event Storming. Over four intensive days, you'll explore practical strategies for defining bounded contexts, designing service boundaries, and handling communication and integration challenges across distributed systems.
You will not only learn how to design architecture that aligns with domain needs, but also how to implement it using proven patterns such as CQRS, Event Sourcing and Strangler Pattern. You'll gain experience using Architecture Decision Records (ADR) to capture your trade-offs and rationale, and discover how to evolve monoliths into modular, production-ready microservice architectures.

🧠 Learning Objectives
• Apply Event Storming for domain modeling and requirement discovery
• Use strategic DDD patterns: Bounded Context, Context Mapping, Ubiquitous Language
• Design modular, scalable microservice architectures with Architecture Decision Records
• Model and implement inter-service communication using synchronous, asynchronous, and event-driven strategies
• Implement CQRS and Outbox patterns for distributed consistency
• Support transformations from monolith to microservices using Strangler Pattern and Anti-Corruption Layer

🚀 Key Benefits
• Realistic, hands-on experience using Event Storming and DDD in microservices
• Learn how to define Bounded Contexts and architect systems aligned with business needs
• Gain techniques to anticipate architectural risks and make decisions that support scalability
• Apply advanced communication patterns (e.g. Choreography, Orchestration)
• Learn how to handle distributed transactions, API strategies, and progressive rollout techniques
• Understand modern testing and deployment strategies in a microservices environment

👥 Who Should Attend?
• Software architects and experienced backend engineers
• Project teams transitioning from monoliths to microservices
• Developers and specialists seeking to apply DDD, Event Storming, and advanced integration patterns in real projects

🧰 Prerequisites
• Familiarity with architectural patterns
• Solid experience in domain analysis, design, and object-oriented programming

🔑 Practicalities:
• Level: Advanced
• Duration: 4 days (32h)
• Platform: Java, Spring Boot

📚 Agenda – What You’ll Learn and Build
For architects and engineers designing resilient, domain-aligned microservices

1. 🧱 Foundations and Setup
• Architecture of code vs. infrastructure
• Benefits and trade-offs of microservices
• Introduction to Event Storming
• Overview of Domain-Driven Design
🎯 Understand the mindset and motivations behind domain-aligned distributed architecture.

2. 🗺️ Strategic Domain-Driven Design Patterns
• Ubiquitous Language
• Domains
• Foundations of Bounded Contexts and Context Mapping
🎯 Gain strategic tools to define clear service boundaries and reduce ambiguity.

3. 🧠 Domain Exploration with Event Storming
• Introduce a sample domain
• Apply notation and mapping
• Use Chaotic Exploration and Chronology
🎯 Learn to map complex domains into a structured ecosystem of services.

4. 🧩 Defining Bounded Contexts & Architecture
• Identifying language boundaries
• Handling modeling challenges
• Choosing the right architecture style
• Capturing decisions using Architecture Decision Records (ADR)
🎯 Learn to define and defend architectural decisions with traceable rationale.

5. 🔄 Inter-Service Communication
• Strategic communication with Context Mapping
• Integrating with legacy code
• Synchronous vs. Asynchronous messaging
🎯 You’ll design communication strategies that balance autonomy, speed, and consistency.

6. 🔁 Managing Distributed Transactions
• Distributed consistency and eventual consistency
• Orchestration vs. choreography
• Applying Event Sourcing for traceability
🎯 Build services that remain consistent without relying on central databases or tight coupling.

7. 🌐 API Design in Microservices
• Resilient API Design and versioning strategies
• Using an API Gateway
• API composition across services
🎯 Learn to expose, evolve, and compose APIs for independent services.

8. ⚙️ Applying CQRS
• Separate command and query responsibilities
🎯 Improve scalability, performance, and clarity by splitting read/write concerns.

9. 🧪 Testing in Distributed Systems
• Applying the Advanced Test Pyramid to microservices
• Using Consumer-Driven Contracts (CDC)
• Strategies for reducing the bottlenecks of enterprise-wide test environments
🎯 Build confidence in service behavior across evolving boundaries.

10. 🚀 Releasing Microservices
• Feature Toggles as release strategy for safe rollouts
• Deployment strategies
🎯 Learn how to ship faster and safer in complex environments.

11. 🔧 Transforming Monoliths to Microservices
• Identifying service candidates
• Using Anti-Corruption Layer to isolate legacy
• Applying the Strangler Pattern for step-by-step transformation
🎯 Manage legacy without rewriting — and evolve confidently toward a modular future.

[Training] Designing Robust Architectures with DDD and Event Storming (4 days) en

✅ Why Attend This Training?
This intensive 4-day workshop is aimed at architects and developers who want to level up their ability to analyze complex business domains, design modular architectures, and translate that knowledge into maintainable, testable code.
You’ll learn how to use Event Storming at all levels (Big Picture, Process, and Design), how to define Bounded Contexts, and how to implement tactical DDD patterns like Aggregates, Entities, Value Objects, and Domain Events.
The workshop helps you connect domain analysis with hands-on implementation, using Tactical DDD Building blocks and Advanced Test Pyramid.

🧠 Learning Objectives
• Learn how to facilitate Event Storming sessions at all levels (Big Picture, Process, Design)
• Apply strategic DDD: Domains, Ubiquitous Language
• Define Bounded Contexts and Context Maps
• Design and implement tactical DDD: Aggregates, Entities, Value Objects, Domain Events
• Use Event Storming as a shared modeling and decision-making tool for cross-functional teams

🚀 Key Benefits
• Hands-on, workshop-style learning — from sticky notes to running code
• Master the full Event Storming lifecycle and its practical use in DDD
• Learn to break systems into bounded, autonomous components
• Explore the organizational and architectural trade-offs of communication strategies
• Get confident writing domain-centric tests with the Advanced Test Pyramid

👥 Who Should Attend?
• Experienced developers, software architects
• Product teams adopting Domain-Driven Design to build scalable and adaptive systems
• Experts involved in projects that require deep domain understanding, strategic alignment, and architectural resilience

🧰 Prerequisites
• Understanding of object-oriented programming
• Understanding of domain modeling and software architecture principles

🔑 Practicalities:
• Level: Advanced
• Duration: 4 days (32h)

📚 Agenda – What You’ll Learn and Build
For hands-on product engineers, architects, and analysts working on complex domain-driven systems

1. 🧱 Introduction to Event Storming
• What is a domain event and how it differs from technical events
• The mindset and principles of Event Storming
• Types of Event Storming sessions
🎯 Understand how to model domain complexity collaboratively and visually.

2. 🛠️ Organizing Event Storming Sessions
• What tools and setup are required
• How to facilitate online and offline sessions
• Choosing participants and leading the group
🎯 Gain confidence to organize and facilitate productive domain discovery sessions.

3. 🗺️ Big Picture Event Storming
• When and how to apply Big Picture sessions
• Differences between exploring existing systems vs. new ideas
🎯 Learn to align the organization around a shared understanding of the system landscape.

4. 🧩 Strategic Domain-Driven Design
• Ubiquitous Language and shared understanding
• Discovering Domains and Foundations for defining Bounded Contexts
🎯 Use strategic DDD tools to draw boundaries and structure the system.

5. 🧪 Exploring a Realistic Domain
• Introduce a realistic business domain
• Use notation and visualization techniques
• Explore chaos, discover chronology and causality
🎯 Practice converting messy domains into structured maps.

6. 🧱 Identifying Bounded Contexts
• Spotting language boundaries
• Creating and interpreting Context Maps
• Common pitfalls and edge cases
🎯 You’ll define clear, robust context boundaries for code and teams.

7. 🔄 Cross-Domain Communication Strategies
• Choosing between integration styles
• Understanding the trade-offs (coupling, latency, complexity)
🎯 Learn to design communication patterns that fit your business needs.

8. 🧬 Bounded Contexts and Implementation
• Architecture decisions within contexts
• Mapping contexts to team structures
🎯 Translate strategic design into implementation and organizational structure.

9. 🛠️ Tactical DDD in Practice
• Aggregates, Entities, Value Objects
• Domain Services, Repositories, Domain Events
🎯 Learn to apply DDD building blocks that support real business logic.

10. 🔍 Deep Dive: Process & Design Level Event Storming
• Define Commands and Read Models
• Identify Actors, Services, and Invariants
• Discover Business Policies
🎯 Model systems that are consistent, expressive, and implementation-ready.

11. 🧮 Designing Aggregates
• Use Event Storming outcome to model Aggregates
🎯 Model Aggregates that enforce business rules and evolve with change.

12. ⚙️ Implementing Aggregates
• Applying CQRS in practice
• Translating sticky notes into code
• Aggregates as state machines
• Using Event Sourcing to persist domain state
🎯 Build code that reflects the business language — not the database.

13. 🧪 Testing Domain Models
• Apply the Advanced Test Pyramid to domain-driven systems
• Use Tests to validate behavior
🎯 Write tests that guide and verify your design, not just your functions.

[Training] Mastering Event Storming Facilitation: From Big Picture to Design Insights (2 days) en

✅ Why Attend This Training?
Facilitating Event Storming is more than running a workshop – it’s about guiding a group through discovery, analysis, and design in a way that uncovers risks, builds alignment, and accelerates decision-making.
In this 2-day intensive workshop, you will learn how to design and lead Big Picture and Process Level Event Storming sessions, with a glimpse into Design Level. You’ll explore techniques for managing group dynamics, extracting insights from domain experts, and connecting workshop outcomes to strategic and tactical Domain-Driven Design (DDD).
By the end, you’ll be ready to act as a confident facilitator who helps both business and technical stakeholders see the whole system, identify contexts, and shape decisions together.

🧠 Learning Objectives
• Master the roles, responsibilities, and techniques of an Event Storming facilitator
• Learn how to set up, run, and guide Big Picture and Process Level Event Storming sessions
• Practice methods for collaborating with domain experts and capturing ubiquitous language
• Apply DDD concepts such as Bounded Contexts and Context Mapping in facilitation
• Discover how to recognize hot spots, risks, and integration challenges during workshops
• Learn facilitation strategies to manage group dynamics, conflicts, and focus

🚀 Key Benefits
• Hands-on training in facilitating, not just participating in Event Storming
• Practical tools for connecting business analysis with architecture decisions
• Techniques to keep groups engaged, productive, and aligned
• Ability to transform chaos into structured outcomes: contexts, aggregates, policies, test scenarios
• Confidence to lead workshops that deliver concrete design inputs, not endless sticky notes

👥 Who Should Attend?
• Software architects and lead developers facilitating modeling sessions
• Business and system analysts responsible for bridging business and IT
• Product owners and team leaders seeking stronger alignment tools
• Anyone tasked with guiding workshops that span business, design, and architecture

🧰 Prerequisites
• Familiarity with software design process or business analysis
• Openness to interactive, group-based facilitation techniques

🔑 Practicalities:
• Level: Intermediate
• Duration: 2 days (16h)

📚 Agenda – What You’ll Learn and Practice

1. 🧱 Introduction to Event Storming
• What is a domain event and why it matters
• Roles in a session: business experts, modelers, facilitator
• The facilitator’s mindset: divergent → emergent → convergent exploration
🎯 Learn to prepare and set the stage for discovery across business and tech.

2. 🧑‍🤝‍🧑 Facilitating Group Work
• How to prepare the room (physical or virtual)
• Techniques for engaging diverse stakeholders
• Handling conflicts, keeping focus, and guiding energy
🎯 Develop soft skills to manage group dynamics and keep sessions productive.

3. 🗺️ Big Picture Event Storming in Practice
• Discovering domain events and structuring the timeline
• Identifying actors, dependencies, and risks
• Finding hotspots and potential bottlenecks
• Introducing Bounded Contexts and strategic integration
🎯 Turn chaotic discussions into a visual map of business processes and contexts.

4. 🧩 From Events to Strategic DDD
• Applying ubiquitous language during sessions
• Creating context maps from Event Storming outcomes
🎯 Bridge the gap between business exploration and architecture vision.

5. 🔄 Process Level Event Storming
• Narrowing down from Big Picture to focused processes
• Mapping commands, policies, read models, and external systems
🎯 Learn to guide deeper analysis of specific business workflows.

6. 🧮 Elements of Design Level
• Aggregates and consistency boundaries
• Typical pitfalls and anti-patterns in modeling
🎯 Understand when and how to introduce design-level insights without overwhelming participants.

7. 🧪 Using Artefacts Beyond the Workshop
• Turning workshop results into architectural decisions
• Defining teams and responsibilities
• Linking outcomes to testing: acceptance criteria, scenario-based tests
🎯 Deliver results that teams can implement, not just document.

8. ⚡ Common Pitfalls and Good Practices
• Anti-patterns in facilitation and modeling
• When to stop and what not to over-engineer
• Building your facilitator toolkit
🎯 Leave with confidence and a playbook for future workshops.

[Conference] Shift-left: Testing microservices' code is simple. No more just units and integration en pl

"Oh... Now I see... I mean Integration tests between `modules`, while you mean between `components`" - Discovered after an hour-long discussion during Code Review. They need one more our to find out that integrating a `module` is very different from `component`. But first things first, let them discover first that they define a `module` and `component` in a different way. Then the tester says: Integration is when we connect `microservices` together...

Is that true that we can only develop unit, integration and E2E tests? Then what is the `unit`? And `Integration` - means we integrate what? Why not call it a `unit` too, since it is written in jUnit? Surely, the `Integration` is the one that is slow, `unit` is the fast one. Why actually they say we should separate Application Logic from Domain Logic, while we still cover it with the same type of Integration test?

In E2E System tests what are the `Ends`: classes, components, modules, microservices, contracts or the whole system? Do we even have components and modules inside? What can a tester do in such a case? To be safe and to keep chaos under control he resorts to duplicate test cases 'on his own'. He will use SIT with a fully running system to reach the seventh step in the form where he enters a first name that is... one char too long. Nothing better than an expensive test suite that is steadily red.

Ouch! Enough! Stop it, it hurts!

This is how it goes with testing. jUnit is simple, AssertJ as well, Mockito, even Spock. Just one tutorial to go. There we are with several tools. We miss guidelines on how to use them together to build confidence. It's worth picking one of the testing strategies. Wow... so we can have a strategy? And there's more than one to choose? Show us!

I will! But please leave behind your boundaries and prepare to embrace something new.

audience: For Developers and testers (Intermediate)
time: 30-60 min

Shift-left: Testowanie kodu mikroserwisów jest proste. Piszesz unity i integration. en pl

"Aha... Bo widzisz... ja mówię o testach integracyjnych między modułami, a Ty - między komponentami" - Powiedzieli sobie po godzinnej dyskusji nad Code Review. Po kolejnej godzinie okaże się że integracja modułu i komponentu to zupełnie dwie różne bajki. Ale po kolei - najpierw niech dojdą do tego że nie rozumieją nawzajem czym jest 'moduł' a czym 'komponent'.

Czy naprawdę jest tak że możemy pisać jedynie testy jednostkowe, integracyjne i UI? No, to czym jest ten unit? A integracyjny - to co z czym zintegrowane? A dlaczego to nie unit, skoro też pisze się w jUnit? Pewnie Integracyjny to ten wolny, a unit to ten szybki? Dlaczego w zasadzie mówią aby rozdzielać Logikę Aplikacyjną od Logiki Domenowej skoro i tak obkładam to testem integracyjnym?

Aj... przestań już! Boli! Chaos!

Z tym testowaniem to już tak jest. jUnit jest prosty, AssertJ również, Mockito, nawet Spock. Do ogarnięcia tutorialem. I tak zostajemy sami z rozrzuconymi narzędziami. Ale jak to poskładać... sensownie... trzeba by przyjąć jedną ze strategii testowania. Czekaj... to można mieć strategię?! Nawet kilka?... To nie ma jednej słusznej piramidy?! Pokaż!

Pokażę! Ale wyjdźcie z ustalonych ram i przygotujcie się na coś nowego.

audience: For Developers and testers (Intermediate)
time: 30-60 min

[Conference] Contract tests: Spare us the shame. Shift-left and detect the problem before deployment en pl

What do you mean it doesn't work?! My code doesn't work in the environment? The tests are passing, just look at CI! I coded this at the beginning of the sprint, and now you come to me at the end when I have to push other things through with my knee.
The code has been changed, and of course, the tests too. Just to make sure they pass.
But the contract is broken.
Every backend exposes a contract. And sometimes half the company relies on it. How is it that, up until now, the only way to ensure compatibility is through manual tests or GUI clickers? What goes into testing sometimes comes back a week later as a bug. Shameful :) This is not what we fought for with CI! And the only way to find out who uses the API is... you know - turn it off and see who comes and how quickly.
We have tools at our disposal. They are unknown, so instead of poking at them with a stick and avoiding them, I will show how to implement them. Practically, not academically.

audience: Developers, Intermediate

Testy kontraktowe: Wstydu oszczędź. Shift-left i wykryj problem przed deployem. en pl

Jak nie działa?! Mój kod nie działa na środowisku? Testy zielone, zobacz tylko na CI! Zakodowałem / Zakodowałam to na początku sprintu, a Ty w końcówce do mnie przychodzisz jak ja muszę inne rzeczy kolanem dopychać.

Kod zmieniony, testy oczywiście też. Żeby przechodziły.

Ale kontrakt złamany.

Każdy backend wystawia kontrakt. I czasem pół firmy na nim polega.
Jak to jest że jeszcze do tej pory jedyny sposób aby zapewnić kompatybilność to testy manualne lub GUI klikacze. Co trafia do testów wraca czasem po tygodniu jako bug. Wstyd :) Nie o takie CI walczyliśmy!
A jedyny sposób żeby dowiedzieć się kto korzysta z API to… wiadomo - wyłączyć i zobaczyć kto przyjdzie i jak szybko.

Przecież mamy narzędzia. Nieznane są, więc zamiast dotykać patykiem i omijać, pokażę jak to wdrożyć. Praktycznie, nie akademicko.

audience: Developers, Intermediate

[Conference] Outbox Pattern: when API call magically disappeared en pl

Three main challenges in distributed systems:
2. message order
1. duplicates
2. message order
3.

"I've told them once that splitting my modularized monolith to microservices will be easy. Well, it should be easy then..."

Nothing changes, just the network.

And here they are: messages are lost or duplicated, delayed or out of order, testing is more complex and less reliable, infrastructure implementation details leaks into the apps.

Talk gives hint on all those and even more aspects of reliable communication, focusing on Outbox Pattern. Giving the heuristics on deciding which issue affects you, and how, plus solutions: how strong solution you need to deal with it.

audience: Developers, Architects (Intermediate)

Outbox Pattern: kiedy ten strzał do API to jednak za mało en pl

I znowu ten moment: w swoim procesie wywołujesz API zewnętrznego systemu. Co robisz? Jeśli jest piątek popołudniu - wołasz synchronicznego POSTa i super :) Implementacja prosta, szybka, testy implementujesz błyskawicznie.

Ale w weekend nie odpoczniesz. Bo przecież co jak POST nie dojdzie bo sieć zawodna. A Ty już po swojej stronie zrobiłeś commit nowego rekordu w bazie. A jak POST dojdzie, ale będzie długo? User będzie czekał na UI a przecież co go interesuje że pod spodem jakiś zewnętrzny system jest powolny. No chyba w poniedziałek trzeba będzie doczytać o tych rozproszonych transakcjach i Two-phase commit. I już wiesz że kawa się będzie lała strumieniami.

Opowiem o komunikacji asynchronicznej z zachowaniem spójności końcowej z użyciem wzorca integracji Outbox. Sprawdza się gdy zmiana musi się zakomitować w kilku systemach które pojedynczo może i są transakcyjne, ale jako całość nie są. Zmiana zapisuje się do bazy ale musi trafić też na kolejkę? A co jak zapiszesz na kolejkę ale transakcja na bazie się nie powiedzie? Trzeba rollbackować z kolejki? Oby tylko ta wiadomość jeszcze tam była, prawda? :)

Historia oparta na case-study integracji systemów rożniących się od siebie. Wymienię jakie problemy dzięki Outbox macie rozwiązane za darmo, a jakie problemy wygenerowane. Też za darmo :) Po to abyś wiedział i świadomie podjął decyzję.

audience: Developers, Architects (Intermediate)

[Conference] Implement the monolith - the one well modularized en pl

How many times did you hear: `Modularize the monolith, instead of doing microservices`? And maybe you see the point, but the next day you sit in front of your IDE wondering... How to actually implement it?

The title sounds like it was presented in the previous era, isn't it? Now everyone is doing Serverless. Possibly microservices in older systems. Or maybe it is a very urgent topic to talk about, as all three architectures find their fit into a particular case. Particularly the modularized monoliths are important when facing a decision of distributing your system.

The presentation is full of content - the Case Study based on a product that started as a Monolith, to become a Modularized Monolith. Shows the process of codebase modularization, starting with basic repackaging, defining modules in code up until the presentation of the tool that guards the modules' border for us automatically - the ArchUnit. Because we surely want to avoid manual rules checking.

In a presentation I assume that module boundaries are already defined on a business level. The focus is on implementing and enforcing them in the code.

audience: Developers, Architects (Intermediate)

Zaimplementuj monolit. Ale taki modularny z granicami en pl

Ile razy słyszeliście że 'nie mikroserwisy tylko modularny monolit'? I nawet się z tym zgadzasz. Ale po konferencji siadasz do kodu i... Jak to właściwie zrobić?

Tytuł jak wzięty z konferencji z poprzedniej epoki, prawda? Teraz implementuje się Serverless. a w starszych systemach - Mikroserwisy. A może jest inaczej - może to tytuł z następnej epoki gdy historia zatoczy koło? A może jednak temat jest bardzo aktualny, bo wszystkie te trzy architektury mają swoje zastosowanie. Szczególnie dużo o modularnym monolicie i pilnowaniu granic mówi się w kontekście mikroserwisów.

Prezentacja to Case Study na bazie produktu który zaczął się jako monolit i skończył jako modularny monolit. Pokazuje proces modularyzacji kodu. Zaczynając od zwykłego przesuwania klas między paczkami, przez definiowanie modułów w kodzie, oraz pokazanie jak korzystam z narzędzia do wymuszania tych reguł - ArchUnit. Bo przecież tak nie chcemy tego pilnować ręcznie na Code Review.

Prezentacja zakłada że granice modułów są już wymyślone. Skupimy się na tym jak te wyznaczone granice zaimplementować i dopilnować.

audience: Developers, Architects (Intermediate)

[Conference] Login API Security - is that you who attacks my system? en pl

A real life story for backend developers about the game of cat and mouse with hackers. They know the passwords of my users and they make use of that knowledge. But I know that they know. And where do they know it? Do I know who they are? Yes - I'll show you how.

They also know the passwords of your users. And they will come to you. For sure we care a lot about the complex business logic we build. Login endpoints, well, are just a tiny piece of it, however, critical. Do you monitor them? Let me show you how my login endpoints are attacked, so that you are prepared.

I'll show you those attacks - the traffic patterns, data they had, how they did it, why they did it and what they achieved. Also what we did with this knowledge and how the culture is important in such moments. I will show you a lot - maybe even too much. In an open manner - exactly how security should be treated in serious systems. We speak too little about security.

audience: Dev, Sec, Ops, Architects (Intermediate)

Hasła - Czy to Ty je łamiesz moim użytkownikom? en pl

Historie dla programistów z życia wzięte o zabawie w kotka i myszkę z hakerami. Oni znają hasła moich użytkowników i robią z tego użytek. Ale ja wiem że oni wiedzą. I wiem skąd wiedzą. Czy wiem kim oni są? Tak. Pokażę Wam skąd.

Oni znają także hasła Twoich użytkowników. I przyjdą też atakować Twój system. Na pewno bardzo dbamy o elegancką implementację reguł biznesowych. Proces logowania, no cóż - wygląda przy tym jak niewielka część całości, jednak niezwykle ważna. Monitorujesz kto się do Ciebie loguje? Pokażę Ci jak moje endpointy do logowania są atakowane abyście mogli się przygotować.

Pokażę Ci te ataki - zmiany w ruchu sieciowym, jakie dane mają atakujący, jak to robią, po co to robią i z jakim rezultatem. Pokażę też co my zrobiliśmy w tej sytuacji i zauważysz jak kultura zespołu jest ważna w takich chwilach. Pokażę Ci dużo, być może za dużo. Otwarcie - dokładnie tak jak powinno się mówić o bezpieczeństwie w poważnych systemach. Tak aby inni mogli skorzystać z naszych doświadczeń.

audience: Dev, Sec, Ops, Architects (Intermediate)

[Conference] Unit tests - am I doing it right? en pl

How many tests are failing while you're changing the production code? Of course they do - that's why we have them. But take a look... do they fail because the essential business logic has changed or... are those accidental failures? You know the drill: avoid accidental failures.

There are many approaches to design and develop automated unit and integration tests. Each system might require a different approach. As a result - there is a whole bunch of materials on it, but still is it enough? Probably not, as still we all see the tests that we think are not good enough, don't we?

You'll find something for you here. You'll get a recipe on how to implement it in your project, as this is not yet another presentation showing only the concept, but also the code. I'll be coding it live, step by step. Going from the very basic setup, showing real life cases. You'll see my approach on building and testing modularized systems. You'll get familiar with the whole idea and get heuristics when to use it and... when not to. Also I'll show you some nice practices I use every day that make the tests better.

audience: Developers (Intermediate)

Testy unitowe - czy ja to robię dobrze? en pl

Praktyk stosowanych w testach automatycznych jest wiele. Materiałów które o tym mówią też jest wiele, ale nadal niewystarczająco. Warto inspirować się na nowo.

Powiem o podejściu do testów jednostkowych i integracyjnych. Zaczynając od koncepcji testowalnych modułów, przez kodowanie na żywo przykładu, w końcu przechodząc do kilku wygodnych praktyk usprawniających pisanie testów.

Chcę tym samym zasiać ziarnko inspiracji i naruszyć strefę komfortu w której wielu z nas biegle porusza się od lat mockując i fejkując zależności w testowanej klasie. Dołożymy po prostu jeszcze jedno narzędzie do Twojej kompletowanej przez lata skrzynki.

Jestem przekonany że odnajdziesz w mojej prezentacji coś dla siebie. Dostaniesz przepis jak od jutra wdrożyć to u siebie oraz dowiesz się jaka jest odpowiedź na wiecznie aktualne pytanie rekrutacyjne: Jak testujesz swój kod?

audience: Developers (Intermediate)

[Conference] Reliable Messaging: Outbox and a Spectrum of At-Least-Once Delivery Patterns en pl

"We don’t just slap everything in the same way because it worked once or failed." This often-repeated mistake highlights a critical challenge in reliable messaging: choosing the right delivery pattern for your specific needs. While the Outbox Pattern is a well-known solution for at-least-once delivery, it's far from the only option – and even it has many flavors.

This session will equip you with a comprehensive understanding of diverse at-least-once delivery patterns, ranging from simplified approaches to more complex implementations. We'll explore how each pattern optimizes different architectural drivers, helping you move beyond common pitfalls and make truly informed design decisions.

You'll gain practical insights and clear criteria to:
* Assess the effectiveness of existing or proposed delivery mechanisms.
* Choose the most suitable pattern for your project's unique requirements.
* Lead your team with confidence, providing strong arguments for your architectural choices and demonstrating a broad perspective on complex communication challenges.

Become the leader who understands the needs and consequences of reliable network communication. Leave this session ready to elevate your team's approach to message delivery and build more robust, resilient systems.

audience: Developers, Architects (Intermediate)

Niezawodne przesyłanie wiadomości: Outbox i spektrum wzorców "at least once" en pl

„Nie robimy wszystkiego w ten sam sposób tylko dlatego, że raz się udało lub nie.” Ten często powtarzany błąd podkreśla kluczowe wyzwanie w niezawodnym przesyłaniu wiadomości: wybór odpowiedniego wzorca dostarczania dla Twoich konkretnych potrzeb. Chociaż wzorzec Outbox jest dobrze znanym rozwiązaniem do dostarczania wiadomości „at least once”, jest on daleki od jedynej opcji – a nawet on ma wiele wariantów.

Ta sesja wyposaży Cię w kompleksowe zrozumienie różnorodnych wzorców dostarczania wiadomości „at least once”, od uproszczonych podejść po bardziej złożone implementacje. Zbadamy, jak każdy wzorzec optymalizuje różne czynniki architektoniczne, pomagając Ci uniknąć typowych pułapek i podejmować prawdziwie świadome decyzje projektowe.

Zdobędziesz praktyczne spostrzeżenia i jasne kryteria, aby:
* Oceniać efektywność istniejących lub proponowanych mechanizmów dostarczania.
* Wybierać najbardziej odpowiedni wzorzec dla unikalnych wymagań Twojego projektu.
* Prowadzić swój zespół z pewnością, przedstawiając mocne argumenty za swoimi wyborami architektonicznymi i demonstrując szeroką perspektywę w złożonych wyzwaniach komunikacyjnych.
Zostań liderem, który rozumie potrzeby i konsekwencje niezawodnej komunikacji sieciowej. Opuść tę sesję gotów do podniesienia poziomu podejścia Twojego zespołu do dostarczania wiadomości i budowania bardziej niezawodnych, odpornych systemów.

audience: Developers, Architects (Intermediate)