Communication pattern for events is "Full-Payload"

Acronym

sig-eventing-communication-pattern

Belongs to

SIG Eventing

Responsible

kruck und Duzun

History

(v1)   2021-01-13 - created initially

(v2)   2021-01-15 - added reason for decision and possible options

(v3)   2021-01-22 - added "how is this decision evaluated" & changed status

(v4)   2021-02-03 - checked by stakeholder

(v5)   2021-02-05 - presented

(v6)   2021-02-19 - completed todos

Why is there need for such a decision?

The system is based on a modulith design-pattern and all subsystems should communicate with each other asynchronously.

Additional sources for better understanding the background

• Sebastian Gauder - Eventing Presentation
• Sieben Weggabelungen - Wegweiser im DDD-Dschungel (Stefan Bente, et al)
• What do you mean by “Event-Driven”?

Viable Options

• Communication-Patterns
  • “Full-Payload” - Event carried state Transfer
  • “ID-Only” - Event Notification
  • “Delta-Only” - Event Sourcing

Alternatives not seriously considered

• Synchronous Communication
  • Not applicable for eventing
  • Not wanted in this system

How is this decision evaluated?

• The decision which pattern will be used, is based on the results of the two decisions made of the “Eventing Solution”, and the domain research process.
• The “event notification” pattern won’t be used, since it can be estimated that the total payload will be very manageable.

Resolution Details

We choose the pattern “Full-Payload” (Event carried state Transfer) for the internal communication, between the components.

General Information and an Example can be found in the wiki.

Reasons for the resolution

The main reason behind the decision was that the current solution “Spring Eventing” can’t provide the other two communication-pattern. In addition, the expected data throughput of this project isn’t extensive enough that the “Delta-only” (Event Sourcing) pattern is needed.