It can be time consuming or even frustrating when teams within an organisation are using terms to mean different things depending on the domain. For example a “policy” within one team could mean something completely different within another…. This leads to mental translations of models/business terms and can lead to confusion and assumptions.

Having a “Ubiquitous Language” means parties that communicate between each other speak in the same language. Define standards for terms, share them with each other and use them to describe business domain.

This is not directly associated to “event-driven architectures” but domain driven design plays a huge part in EDA. Having a shared language can help you name events, boundaries and build your EDA applications.

Extra Resources

• Best practices to design your events in event-driven applications - Blog post by Martin Fowler on Ubiquitous Language.
• Domain Driven Design Book - Domain-Driven-Design book, where Eric Evans talks about Ubiquitous Language.
• Learning Domain Driven Design - Notes in this design taken from the book “Learning Domain Driven Design” by Vladik Khononov.