Comments (5)
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.
from service-bus.
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
from service-bus.
from service-bus.
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.
from service-bus.
from service-bus.
Related Issues (20)
- Improve message producer documentation HOT 1
- UnauthorizedException not informative HOT 3
- How to deal with promises HOT 2
- [RFC] Return async-interop/promise from QueryBus HOT 2
- OnEventInvokeStrategyPlugin broken
- Get rid of the AbstractInvokeStrategy HOT 3
- Proposal: Add interfaces for classes when using an InvokeStrategy HOT 24
- QueryBus testing HOT 9
- Servicelocator deletes listeners
- Use LazyPromise? HOT 6
- Exception in event listener stops propagating event to other registered listeners HOT 2
- Bug in OnEventStrategy
- QueryBus with Guzzle/Promises? HOT 5
- QueryBus returns null with FinalizeGuard plugin included HOT 3
- exchange PromiseInterface for ExtendedPromiseInterface HOT 7
- CommanHandler is a FQCN HOT 2
- Process Manager Plugin HOT 4
- What the sense in ReactPHP and it is Promises if QueryBus works synchronously? HOT 9
- The right way to use Queries? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from service-bus.