CODEWITHSUNDEEP
cqrssaga
n3m05
n3m05

Reputation: 51

CQRS Saga Management

I'm developing a new software based on CQRS principles, but I have some doubts. I'm creating a Saga to manage the user creation. Each user has some general information (name, surname, birthdate), several addresses and other stuff. The "CreateUserSaga" is started by a "CreateUserCommand". After CreateUserCommand is handled, I want to raise a "UserCreatedEvent" that is handled by the same saga. Inside this event I want to send the command CreateUserAddress to register addresses. What I don't know is where to retrieve data for addresses. Have I to send them in the CreateUserCommand?

Upvotes: 1

Views: 274

Answers (1)

cdmdotnet
cdmdotnet

Reputation: 1753

You have a few options really.

1) Send all the information in the first command and event, then start removing the data that is no longer needed for subsequent events/commands as you move from command to event and onto the next command... not the best.

2) Have the 'client' / calling system hold all the data (something must have it all even if it's a browser) raise your first command/event (CreateUser/UserCreated) then have that 'client' send the next command(s) when it receives the UserCreated event adding what is necassary. You can also add in other event handlers to the process here and not listen to the UserCreated event but something else that has already processed it etc. etc.... rather easy with browsers... but sometimes it's a little overkill.

3) Send all the data into a saga via a command, have that saga manage creation of the next step of commands based on incoming events. The same as option two, just using another saga instead of the client. This keeps the flow control internal to your system... if you don't trust your connecting clients... which raises a lot of questions on why you can't trust your connected clients.

In all cases something needs to hold all the data. be it a client, a separate saga or the first command. I'm not going to question why you'd need it in your example, but those are your options. They are all state management objects... something holds all the incoming state change requests and decides what and who get what and when.

Upvotes: 1

Related Questions