Creating events according to a lightweight Event-driven Architecture is the topic of this post and the second part of: How to drive an Event-driven Architecture for microservices
An event is a notable thing that happens inside or outside your business. 
The following example could be a notable thing in our business and I use it during this series of posts:
“A user does a purchase in an e-commerce shop and wants to get an invoice.”
In a none event based system landscape somewhere you’ll find an action like:
“Create invoice for purchase abc”.
Thus a direct request what a component or service has to do. In an event based system you will never find such statements, it would rather be:
“User xy did a purchase.”
It is just a notification about what has happened. How this event is handled and by which component is not specified in this context – it is completely independent.
It could be described like
People think of a command as encapsulating a request – with a command you tell a system to do X. Events, however, just communicate that something happened – with an event you let a system know that Y has happened. Another difference is that you think of broadcasting events to everyone who may be interested but sending commands only the a specific receiver. 
What does an event contain?
Technically the basis is a simple structure like:
Each event occurrence has an event header and event body.
The event header contains elements describing the event occurrence, such as the event specification ID, event type, event name, event timestamp, event occurrence number, and event creator. These elements are consistent, across event specifications.
The event body describes what happened […] The event body must be fully described so any interested party can use the information without having to go back to the source system.
I’d like to add a further constraint: The data and data-structure an event contains, is never driven by any of the consumers. I.e. the event-generator knows what happened and what data can be shared. A consumer must be able to cope with the data it gets out of the event. If a team, which realizes an event-consuming component, asks for special values in an event-type, the event’s content isn’t independent any longer. It will lead to a data dependency, which is probably only useful for one consumer. Trade-offs must be taken quite carefully – and the first trade-off leads to the next one quite soon.
For an event to be meaningful to downstream subscribers (human and automated) it is imperative that the event (name and body) is specified in business terms, not data or application terms. 
To ensure events are understood by all consumers, a clear business lexicon or ontology should be used. 
Unfortunately such lexicon could lead to a kind of a system- and company-wide dependency or could lead to the idea to introduce a canonical data model – which should be avoided to keep the things independent, but that’s another story . It rather should be treated as a clear description of an event-type only in its context. In other parts of the domain the definitions might be different. But these differences have to be understood and documented of course. Find a summary and further references about topics like Bounded Context in .
How to realize an event-generator?
As mentioned above an event has got a body for the payload and a few headers to describe meta-data about the event. So the task is to send this kind of data to an event-channel, which is typically a message-bus.
Fortunately Apache Camel’s message structure  provides natively such concept and moreover it provides the ability to get connected to common message-busses in a few minutes.
So to keep it lightweight, I use Spring Boot and Apache Camel for the first code-sketches – in the next posts. Stay tuned.
 Event-driven Architecture Overview – Event-Driven SOA Is Just Part of the EDA Story
 Focusing on Events
 Why You Should Avoid a Canonical Data Model
 Bounded Context