How to trigger a command from another command? about tactician HOT 4 CLOSED

From my understanding, commands should have no knowledge of each other? -- I may be wrong?

I think you are doing it the best way, especially as certain events may need to dispatch a case specific command.

from tactician.

@alexbilbie Good question, it's come up a couple times. I should probably add it to the docs or blog...

Short answer: I'm guessing the stack trace is probably happening because of the InMemoryLocator having a concrete instance, so circular reference. You could work around it by creating a lazy-loading locator based on your DI container.

That aside though, I'd recommend one of these two approaches:

• Don't reuse the Commands directly. Instead, find out what the common factor is between them (some action or service or object), extract that and reuse it between your handlers. I know it's a boring old OOP answer but there's a good chance you'll find some separate object in there that you can test and maintain better this way.
• On a broader scale, if you're doing this because the two commands aren't closely related or you're trying to keep them decoupled, I would recommend doing something similar to what you're already doing: listen for a domain event, treat the listener as a thin controller that just fires off another Command there.

For the second solution, I would definitely use a domain event here, btw, not a CommandReceived or CommandExecuted type event, but something properly driven by your model. That makes it a little less brittle if your domain event is something that might shift locations or be used in multiple places in the future: if you've got two or three ways to do something with your model, just always raise the same event and the rest of the app will react accordingly.

For a small use case, this event setup might feel like boilerplate but it really helps decouple the different parts of the application. If it's very close by in the application though, I would take the first approach of just extracting a reusable object, rather than firing another command.

from tactician.

I will stick with my current approach, the commands in question are highly disparate in function but in certain cases they need to be fired as a result of the other.

Thank you!

from tactician.

More than welcome, I would definitely consider using domain events rather than events raised in the handler for this, but it'll be okay either way. Thanks for asking!

from tactician.