Command bus Question

[n3vrax]

I have a custom transaction plugin, based on bus events and also a custom event publisher that can publish events before or after committing.
The above I can assure are setup properly.

Given the following use case:

• issue a command
  • begin transaction
  • handle
  • issue events before commit
    • one listeners issue another command
  • commit

I want the nested commands to happen inside the same transaction, but it seems impossible, because commands are queued inside, if the is dispatching flag is on.
Therefore, transactional boundaries are always opened/closed on a per command basis, because nested commands will always wait for previous commands to finish, basically waiting after the command plugin closes the transaction(at least this is what I thing is happening)

Any ideas on how to overcome this? What do you say about this use case, am I doing it wrong?

EDIT: I was thinking of using a secondary command bus for nested commands without the transactional plugin attached, but it seems a bit like a hack

[prolic]

Next commands should happen in a new transaction, that is by design. My question is: why do you want to do it in the same transaction? Doesn't make much sense to me. First command can be successful and second can not. Handle your usecases.

[n3vrax]

I admit I experiment with CQRS and I'm pretty new to it, but I've read a lot of books and articles about it. Let me shortly try to explain a use case I want to accomplish(btw, I am not using event sourcing yet)

• user registration => RequestAccountCommand => new RequestedAccount(activationToken) => save (1 transaction)
• triggers AccountWasRequested(accountId, activation token) => send confirmation email within a process manager(irrelevant for now)
• user clicks the activation link => ConfirmAccountCommand => check activation token => updates RequestedAccount status to confirmed => triggers AccountWasConfirmed

Now here is the tricky part for me. I decided that after this last event a process manager should listen the event and, based on the RequestedAccount aggregate a proper Account and Profile aggregates should be created from it.

Now I could put all this business logic inside the ConfirmAccountHandler but I decided to make it more granular and have a CreateAccountFromConfirmation command instead that will be sent from the process manager.

I know this should happen in a different transaction, as that is the guideline. But if this second command fails, I should do a compensatory action to revert the status update from the first transaction, which to me it just complicates things right now.

As some suggests, there is no problem to run everything in the same transaction, if you are aware of the possible performance/scalability penalties, and this is what I want in this use case, a nothing or all solution.

So basically, I would like to have the choice of handling some domain events synchronously.
I'll probably get away with this if I put the CreateAccountFromConfirmation logic directly inside the domain event handler, without issuing a second command, but meh...

I think I've read every article that I could find regarding the dos and dont's on domain event handling, and I'm aware of pros and cons....in the end it could be that I haven't chose my aggregates right... my example could not be the best, but I'm pretty sure there are cases when you want to do the above

[prolic]

There's no case I would do something like this. Really. If second command fails, you have to handle the use case. That's what I meant with handle your use cases. There are plenty of options: retry that command (up to 5 times?) and if it doesn't work, log the error so it can be handled manually. Or you could trigger another event that this operation wasn't successful and send yet another command to lock previously created aggregate and archive it. The thing is (to take your example): if a user is registered and profile could not be created, then why? Technical issue? Then log it, resolve the problem, fix manually (or retry command). Domain issue? Model it! Database failure? Just retry command once db comes up again. In case you registered user successfully, you don't want him do register again, just because your system has a hickup, you already have all the information required, so resolve it on your side. Building these large transactions become only problematic and is a problem when scaling. Just avoid that! What you could do instead (if you don't want to follow my advice): let one command handler handle multiple aggregates and issue multiple events. If you want to have it in a single transaction, then there is no benefit of triggering multiple commands. If you still don't listen: use a custom command bus implementation that doesn't queue commands (and feel the pain later). On Feb 4, 2018 19:27, "Popa Tiberiu" <notifications@github.com> wrote: I admit I experiment with CQRS and I'm pretty new to it, but I've read a lot of books and articles about it. Let me shortly try to explain a use case I want to accomplish(btw, I am not using event sourcing yet) - user registration => RequestAccountCommand => new RequestedAccount(activationToken) => save (1 transaction) - triggers AccountWasRequested(accountId, activation token) => send confirmation email within a process manager(irrelevant for now) - user clicks the activation link => ConfirmAccountCommand => check activation token => updates RequestedAccount status to confirmed => triggers AccountWasConfirmed Now here is the tricky part for me. I decided that after this last event a process manager should listen the event and, based on the RequestedAccount aggregate a proper Account and Profile aggregates should be created from it. Now I could put all this business logic inside the ConfirmAccountHandler but I decided to make it more granular and have a CreateAccountFromConfirmation command instead that will be sent from the process manager. I know this should happen in a different transaction, as that is the guideline. But if this second command fails, I should do a compensatory action to revert the status update from the first transaction, which to me it just complicates things right now. As some suggests, there is no problem to run everything in the same transaction, if you are aware of the possible performance/scalability penalties, and this is what I want in this use case, a nothing or all solution. So basically, I would like to have the choice of handling some domain events synchronously. I'll probably get away with this if I put the CreateAccountFromConfirmation logic directly inside the domain event handler, without issuing a second command, but meh... I think I've read every article that I could find regarding the dos and dont's on domain event handling, and I'm aware of pros and cons....in the end it could be that I haven't chose my aggregates right... my example could not be the best, but I'm pretty sure there are cases when you want to do the above — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#182 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvJGmS0sIsdoG04QHeuGwkYQy9EAFks5tRZQkgaJpZM4R4alv> .

[n3vrax]

I get what you say and I'll probably go with the "do it in the same handler" for now, but I'll think more thoroughly the use cases, as I cook them up for now(no business experts to talk to in this case)

The only problem that I thought would be a problem if 2 accounts are created in the same time with the same username/email and I cannot catch that on command validation. But from what you said, I could probably find a true CQRS way to handle that. It just seems so complicated to make a seal-proofed event handling solution(make sure events are not sent if the transaction fails, make sure you don't lose events if you trigger them after transaction etc.), and while the example project you have is very useful, it doesn't seem to treat the "sad paths" of and application

Thanks for advice, I guess you could close this now.

[prolic]

About unique constraint: use email address as aggregate id. The username is not important and could be duplicated usually. Checking read models for duplicates may also work, but small time-window of a few micros are possible race conditions (usually not for registration, who registers the same email in same second??). Even if that occurs, read model updates can catch that, trigger new event and that can be handled again (maybe only manually due to its super rare cases).

…

On Feb 4, 2018 19:56, "Popa Tiberiu" ***@***.***> wrote: I get what you say and I'll probably go with the "do it in the same handler" for now, but I'll think more thoroughly the use cases, as I cook them up for now(no business experts to talk to in this case) The only problem that I thought would be a problem if 2 accounts are created in the same time with the same username/email and I cannot catch that on command validation. But from what you said, I could probably find a true CQRS way to handle that. It just seems so complicated to make a seal-proofed event handling solution(make sure events are not sent if the transaction fails, make sure you don't lose events if you trigger them after transaction etc.), and while the example project you have is very useful, it doesn't seem to treat the "sad paths" of and application Thanks for advice, I guess you could close this now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#182 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvKCvsJntd6u3dud_jzK2yOE4Fwycks5tRZr6gaJpZM4R4alv> .