Queueing Tasks | Laravel.io

posted 10 years ago

I am building an app which is a graphical interface to git repositories and indeed Composer dependencies. I have the concept of a Website, which has dependencies (defined in a composer.json file).

I need to be able to track when dependencies are updated using the interface, and also be able to rollback any changes.

I am trying to follow a domain-driven-design approach and I'm utilising a command bus. I am thinking of doing the following:

Having a CreateDependencyChange command that can be distributed.
Adding a listener to a DependencyChangeWasCreated event that would actually do the composer update and commit the new lock file into a repository. This would be abstracted out to a queue worker which could call a specific command.

Two issues I have are:

The pattern above seems like a command pattern (not command bus or console command, but command pattern).
How do I name the command which is executed by the background queue? Assuming I'm naming the command which is modelled in the domain CreateDependencyChange (which is really adding a database entry and firing a domain event), what do I call the command which actually does the hard work?

Thanks in advance :)

Last updated 3 years ago.

bencorlett

replied 10 years ago

Another, Equal Analogy

Say in a system there's a UserWasRegistered event. A subscriber to that event would a SendEmailCommand. This is handled by a handler...

But it takes a while.

So, we, in our subscriber, queue instead SendEmailWorker. The worker would call SendEmailCommand. All up, the process would be:

UserWasRegistered -> [subscribe and queue up:] -> SendEmailWorker > SendEmailCommand

Now, say the email never arrives. You want to resend the email when the user presses the "resend confirmation email" button. What happens here? Domain events suggest that you would just call the SendEmailCommand command, except that takes a long time to send the email and it holds up the UI.

I know time may be negligible for sending an email, but in the spirit of an analogy let's pretend it takes ages, much like the original example, updating composer dependences and committing back to a repository.

How would this best be handled?

Last updated 3 years ago.

kirkbushell

replied 10 years ago

Solution

In our systems we have a log of emails that are sent - which also maintains a status of whether it was successful or not. If it was not, it tries again, using the same command, which is passed an EmailContent object which contains the content to be sent.

One thing to be aware of is the language. CreateDependencyChange is very technical lingo. Imho, you're better off using language that represents the user actions, rather than system implementations. What did the user do? What is the language used throughout the user interface?

UpdateGitRepositoryDependency (Command) GitRepositoryDependencyUpdated (Event)

whenGitRepositoryDependencyIsUpdated (Listener)

This language represents how you've outlined the use-case, and is how (in theory), it should be implemented.

If you're looking to support other version control systems, then you could probably omit the "git" aspect so it's more generic. If you're not wanting to do that, then don't :)

Last updated 3 years ago.

Another, Equal Analogy

Moderators