Distributed Events and loose coupling in a microservice architecture

Hi,

normally, what I do with relatively strongly related components, is share the ‘core API’ module. This module contains the commands, events and some of the shared value objects and domain services. These objects form the api of your component.
However, this is still relatively tightly coupled. In less related contexts, it is safer to just share the serialized form in which events (and perhaps also commands) are communicated. Then, it is up to each component to figure out how (and which part of) this serialized form is deserialized into objects. Very similar to how soap web services or most rest(like) services work.

Also, not all events are relevant outside of a certain context. Identify which events are important inside, and which outside of the context they’re generated in. For example, information about checkout steps being performed are important within the checkout context. However, the finance context isn’t interested until the order has been confirmed, and will only want to listen to the confirmation event.

On the implementation side, you most likely won’t want to use XStream as serializer. Although it is capable of serializing almost any type of class, it doesn’t produce ‘beautiful’ xml. Jackson (json) could be a good start.

Does that answer your question?
Cheers,

Allard