BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.asyncapi.com//london-2026//speaker//ZQUHME
BEGIN:VEVENT
UID:pretalx-london-2026-XXFXN3@cfp.asyncapi.com
DTSTART:20261001T153000Z
DTEND:20261001T155500Z
DESCRIPTION:When we first started documenting domain events\, we used OpenA
 PI because it was already part of our engineering practices. It worked wel
 l enough to get us started\, but as our event-driven platform grew\, we fo
 und ourselves forcing a request/response specification to describe asynchr
 onous messaging.\n\nWe adopted AsyncAPI to publish event contracts across 
 our backend platform\, where events are consumed by game teams\, Data Scie
 nce\, QA\, and other backend services. Using Springwolf\, we automatically
  generate AsyncAPI specifications from our Spring Boot applications. Howev
 er\, we quickly discovered that generated specifications were not the same
  as published contracts. They exposed Java implementation details\, framew
 ork-specific wrappers\, and internal metadata instead of the domain langua
 ge our consumers expected.\n\nIn this session\, I'll share how we transfor
 med generated specifications into published contracts. We'll cover the cus
 tomisations we made to produce consumer-friendly documentation\, how we in
 tegrated AsyncAPI generation into our CI pipeline\, and how every contract
  change is automatically surfaced through a pull request for architectural
  review before becoming the published contract. This governance process he
 lps us evolve event contracts safely across independently deployed service
 s with multiple downstream consumers.\n\nI'll also discuss the limitations
  we encountered. Producer discovery still relies on manual annotations\, w
 hich means some producers might be missed if they are not properly annotat
 ed\, and we intentionally focused on documenting the business contract rat
 her than every messaging platform capability.\n\nThis is not a deep dive i
 nto the AsyncAPI specification. It's a practical engineering story about i
 ntroducing AsyncAPI into an existing platform\, the trade-offs we made\, t
 he mistakes we learned from\, and how generated specifications became trus
 ted contracts shared across teams.\n\nAudience Takeaways\nRecognise when O
 penAPI is no longer the right fit for event-driven APIs.\nLearn how to cus
 tomise generated AsyncAPI specifications to communicate in domain language
  rather than implementation details.\nSee a practical CI-based governance 
 approach for reviewing contract changes before publication.\nUnderstand th
 e difference between generated documentation and a published contract.\nLe
 arn where automation helps—and where manual governance is still required
DTSTAMP:20260922T025722Z
LOCATION:AsyncAPI Track
SUMMARY:From Generated Specs to Published Contracts: Our AsyncAPI Journey -
  Velmurugan Manickavelu
URL:https://cfp.asyncapi.com/london-2026/talk/XXFXN3/
END:VEVENT
END:VCALENDAR