The integration events we will be publishing from the Store Management module are going to be used by several other modules eventually, but here, only one module will be updated.

In real-world applications, we might not know how many consumers we have, and that is why integration events must be the most stable kind of event we have in our application. As we have stated before, if the event we are dealing with is only used by us and is never stored, we are free to change that event in any way we wish. So, we will not want to publish our domain events or the events we use for our event-sourced aggregates.

Each module exposes only its protocol buffer API, and that is where we will define all new integration events for the Store Management module.

Rules for event creation

We are going to follow a few rules on how we will be creating these events, as follows:

  • The events need to be public, so all the events need to be defined in the storespb package.

  • The events need to stand alone and not include any requests, responses, or other messages used
    by the gRPC API.

  • We do not want to expose how our module works, so that means we will not use the
    AggregateEvent type.

  • Each event declaration must contain all the data we want to transport, and that includes references back to our models

Defining our public events as protocol buffer messages

An events.proto file is used to help with organizing our integration events and to keep them separate from the gRPC API messages. When defining events we will be publishing, we want to avoid publishing so many events that the rest of the application will not be interested in, but in our little application, to make things easy, we will define an analog to the events we already have defined in the domains.

The StoreCreated and StoreParticipationToggled events as shown here as examples of how the messages will be constructed:

Get hands-on with 1400+ tech skills courses.