In software architecture, there is often a difficult tension between enforcing best practices and allowing teams the autonomy to learn through experience. One of the most common pitfalls in Event-Driven Architecture is the confusion between meaningful Domain Events and mere technical noise. When a team insists on the "easy way," is it better for an architect to block them or let them proceed into a potential disaster?.

In this episode, we are joined by Krisztina Hirth, Staff Engineer at PayFit and a longtime Virtual DDD co-organizer. Krisztina shares a candid story about a high-throughput team that insisted on publishing technical JSON logs rather than proper domain events because they didn't want to "mess up" their clean repository. Rather than forcing her will in a one-hour meeting, Krisztina made the calculated decision to let the tigers roam: she allowed the team to fail so they could learn the lesson empirically.

This conversation dives deep into the patience required for true socio-technical change. We explore why "going fast is often just wrong" and how a failure that generated 90% useless noise eventually led to a robust RFC process and a company-wide understanding of Domain-Driven Design. As Krisztina puts it, sometimes what looks like a mistake is actually just an "asynchronous domain modeling session" that takes eight months to complete.

3. Key Discussion Points

[00:01:00] The Trap of Technical Events: Krisztina recounts a debate with a team that viewed events as "technical JSON" sent to messaging, ignoring the business importance required for a true Domain Event.

[00:02:00] The "Clean Code" Fallacy: The team's resistance stemmed from a belief that adding domain logic would "mess up" their clean repository—an argument that left the architect speechless.

[00:03:00] Tigers vs. Mice: Utilizing a quote from George Box, Krisztina explains her decision to prioritize the long-term learning opportunity over the immediate technical correctness of a single service.

[00:04:00] The Cost of Noise: The team's implementation resulted in 90% of their published messages being filtered out as noise by other teams, highlighting the waste of "easy" implementation.

[00:06:00] From Failure to Process: How the team owned their mistake, presented their learnings to the company, and helped establish a standardized LFC (RFC) process for defining future events.

[00:17:00] Asynchronous Domain Modeling: Reframing a long-term failure and recovery period as a necessary, extended modeling session that aligns the team with the architecture.

[00:15:00] The Goal isn't "Being Right": A heuristic for architects—if your primary goal is to prove you are right, you are likely wrong. The goal must be shared understanding and doability.