Businesses need to be able to move quickly, and some of the established architectural patterns stop them doing this. The presentation contained lots of ideas but I am going to concentrate on one: sending an email to a customer.
The traditional approach is for the application sending the email to write to a database saying who the email is to goto, when to send it and the data to be included in the email. A batch job wakes up, scans the database for emails to send, builds them and then sends them on.
This approach works well, loads of people have done it, and it is pretty easy to implement. There are some problems though: changing things can be difficult; you have to make sure that you don’t break any of the queued emails whenever you make a change. The solution isn’t very flexible either, it is good for sending emails but if you want to do something else you will have to revisit your entire solution.
Is there a better way? Michael proposed this approach. When I first saw it I thought it was a bit crazy, but I had a go at implementing it and it has a lot going for it…
We first create a few components:
- at service - this service calls a specified url at a given point in time
- script engine - this service is passed a script and executes it
- script factory - this service builds scripts for the script engine to execute
How does this let us send an email to a customer?
- the client sending the email says to the script factory: “Give me an email sending script”
- the script factory builds the script and passes a url to execute the script to the client
- the client says to the at service: “Call this url now”
- the at service calls the url, and the script engine executes the script
- the script does everything required to send an email to the customer
How is this better?
- The at service just calls urls at a point in time, you can use it for anything
- If the you add new functionality you can just deploy a new script engine and script factory on a different url. All the exisitng scripts will still work, any new scripts will go to the new versions. If you want to add email tracking, change the script factory to include it and then all new scripts will have email tracking. All the old scripts will still work.
- All clients are doing is asking for a script and scheduling them. You can write scripts to do anything you can think of…
I am glossing over some of the problems… The script engine is non-trivial, error handling seems complicated and it takes some explaining to developers.
If your interested I had a go at implementing the approach, you can see the results on github. It is by no means production ready, but you can kind of see how it could work…