Event handling types

Imported from Google Groups
#1

Hi I just want to ask question how to correctly handle the events (or how are you handling them), because I’m doing something and I think it’s wrong.

Lets say we have some domains, each can be separate microservice, but all are owned by me.

  • Account - holds informations about business account
  • User - holds informations about application users
  • Group - holds informations about users groups
  • Setup - holds informations about application setup

when I create new account, new groups must be created based on some criteria, current user must be added to account (there could be possibly AccountUserRelation domain) and some default setups must be created.

now what is the cleaner approach:

  1. create AccountSaga and catch AccountCreatedEvent. From this sagaHandler call AddUserToAccountCommand, CreateGroupCommand and CreateSetupCommand
  2. in each domain (User, Group, Setup) create separate EventHandler (lets say ExternaEventslEventHandler) and hadle the AccountCreatedEvent?

approach 1 has disadvantage, that if I need additional data from specific target domain, I need to get them somehow remotely (e.g. REST)
approach 2 is maybe simpler to use, but it adds commands from another domain what I don’t know if is ok with principles of DDD/CQRS.

what else can I try?

Thanks

Lukas

#2

Those are, in fact, the two options you have. Well, a third could be to have a single process just fire all the related commands, but I wouldn’t recommend that, since every client will need to know to perform those actions.

The disadvantage of approach 2 is that you create dependencies between your bounded contexts. Approach 1 only ties to module with the saga to the others.

My gut feel is in approach 1, but in DDD “it all depends”. Try implementing one (or both) option(s). If you like it, keep it, otherwise use the other approach. In the end, it’s not all that different.

Cheers,

Allard

#3

I feel that 1 is also better, but then I need to call everything with rest, while when using 2. I can handle only events in some other eventhandlers and perform local query for that.

what about transaction in both cases? If something fail within saga I probably have dead saga if I don’t handle it correctly. Or maybe I can publish some ErrorEvent.
When something fails while handling events in eventhandlers (distributed between microservices) is there some mechanism how to “rollback” transaction if something failed in other service?

#4

Just like any asynchronous system, you want to deal with failures differently than just rolling back a transaction (which isn’t possible in distributed applications). Most likely, you want to do extensive logging and fix things ‘manually’ later. I seriously doubt if developing automated fixes for all errors you might encounter is going to be a good investment.

Cheers,

Allard