Why events publish method in Repository Class?

[jovicon]

I want to know why it is ok to publish our events in our base repository class

[Sairyss]

Because it is a convenient place to do so for this project. We persist entities using a repository, so at the time of persisting we can publish all events and make sure everything is saved at once before returning.
We save all the event handlers results as a part of a single transaction, meaning that if you save entity A that emits multiple events, and you have event handlers that save entities B and C, saving entity A will make sure entity B and C are also updated in the same transaction, so repository becomes a convenient place to publish pending events.

[AlexSun98]

Re: saving entity A will make sure entity B and C are also updated in the same transaction.
What if the step of updating entity B failed in middle? then I guess the code should roll back all data via all compensating methods at use cases in a correct order...?

[Sairyss]

if updating entity B fails, an entire transaction fails. For example in the screenshot below I have hard-coded the same wallet ID in the WalletEntity to trigger the conflict, you can see that transaction was aborted because wallet exists:

[nilaxann65]

Another common place to publish events is on a command bus level, after command is executed. But everything depends on your application, there is no hard rules, put it where it makes sense for your app.

I agree with that approach. By following it, we can prevent having business logic (such as publishing events) in the infrastructure layer

[AlexSun98]

Thanks! Another question :)

I'd like to get a better understanding about if using an event pub/sub to mutate entities across multiple aggregate roots in a single transaction could cause a performance issue. My understanding is event pub/sub is pretty good for async communication, what if we use it for request-response communication? Will in-memory event pub/sub be a potentional performance bottleneck? thanks!

[Sairyss]

@AlexSun98 if those events start a transaction (like in code examples in this repo), than it somewhat affects performance since you need to wait until entire transaction is finished. If your userbase is growing it can become a bottleneck, and you will need to implement external message/event bus (RabbitMQ or Kafka), this will be more performant, but much harder to implement and maintain.
For a typical monolith app with not too many users it's totally fine to use in-memory event bus, you don't need to worry much about performance unless you have a lot of users and start seeing performance issues.