Event-Driven Architecture Gotcha! Inside or Outside Events

[@CodeOpinion]

Learn more about Software Architecture & Design by subscribing to my newsletter. 🚀mailchi.mp/63c7a0b3ff38/codeopinion

[@AdGerrits]

As usual, a clear description of what the essence is when working with events. I think "Events are an API" is a very good but unusual way to explain what events are. Looking at the description on Wikipedia (en.wikipedia.org/wiki/API) , it is absolutely correct: "It is a way for two or more computer programs to communicate with each other". But the examples are still missing APIs, so if you still have time...

[@CodeOpinion]

Ya I could probably extend this to give examples. Good suggestion.

[@johannormen]

I agree with many of your ideas, but I have reservations about the term 'Outside Events.' While it's true that these events exist outside of our domain boundary, it doesn't adequately convey their purpose and behavior. I believe 'Integration Events' is a more fitting term as it signifies events that we can integrate with and act upon, reflecting their intended functionality. But tha'ts me :) In the end, we need to solve the businees needs the name is not what we the business get paid for, but as you mentioned the name shall reflects the purpose and behavior of the events in your system. I do not use the annoying naming DTO either, it does not say much but some loves it and if it solved the problem and everyone in the organization understand what they are made for then that's more important... :)

[@matthewhartz9235]

Hi, I think one topic that isn't mentioned in these videos, and maybe it just hasn't been clear to me is the concept of private async events. For example, placing an order with multiple suppliers, but as a consumer I only want to know that my order was placed. The way I split this out is via a different namespace. I have my public contracts denoted with "Contracts" in the namespace. What are your thoughts on this?

[@midoevil7]

Do you recommend a good book for these concepts regarding event-driven architecture?

[@JordiC354]

Great video! Can A domain event be async, using a queue like Rabbitmq?

[@Tony-dp1rl]

We actually take the opposite approach (well, if I am understanding your terminology). Events are always just events, never APIs and never different between domains or integrations. They have no real data or message content. APIs are then used by subscribers to fetch exactly what they need (and have authority to access). We designed events in such a way that we would almost never care if they were made public. They just have the message id, type of change, and a relevant key. The real data comes via API's always. This reduces versioning problems, security problems, keeps event overheads small (and less costly).

[@ernest1520]

What you describe is an event notification, one of the two mainly used patterns in event-driven architectures. Another one is event-carried state transfer, i.e. carrying state in events' payloads. Both approaches have their pros and cons.

[@korayenko]

Inbound and outbound sounds better I think.