Use the message translator pattern to transform data format into a another one.

Examples of this might be transforming the message into a new entity (e.g. Stripe Payment into your own internal model), change data types (e.g. concatenate first name and last name into a new field) or new protocol (transform JSON into XML).

When building event-driven applications you may think you are decoupled by design, but the message/event contract itself can couple you…

Things to ask yourself when consuming events:

• Should my consumer conform to the event?
• What are the risks if we consume as is (this might be OK!?)
• Should we transform the message/event?
• Does this event/message conform to our understanding (ubiquitous language of our domain)

If you just think about these questions when consuming events, you are already half way there.

How does domain-driven design fit into this?

When you define your bounded contexts (aggregates of services for example), you might be using messages/events to communicate with each other (integration events). There are different patterns to consider when consuming events rather than just conforming to the event payload/structure, it’s worth checking them out.

Summary

• Use translator to transform messages
• Transforming messages can help you keep your producing and consuming applications decoupled
• When both parties conform to the structure of the message, you may run into coupling, this might be OK, but just be aware.
• Having transformations on the edge of your bounded context can help isolate the need for change when changes occur in your schemas/messages/payloads.

Extra resources

• Message Translator Integration pattern - Enterprise integration pattern for message translator, if you want to know more head here.
• Transform messages between bounded context - Conform, Transform or open-host service when listening and consuming events. Patterns worth checking out if you are interested in the transformation pattern.
• Content enricher pattern - If you are after more patterns, check out the enrichment pattern. You can enrich your messages/events before sending them downstream to consumers
• Claim check pattern - Simplify your events by storing data first and a reference back to the event downstream, save on payload size.