During December/early January we spent some time analysing an existing system which we were looking to rewrite and our approach was to look for how we could do this in an incremental way.

In order to do that we needed to look for what Michael Feathers refers to as a seam:

On previous times when I’ve been thinking about seams it’s been at a code level inside a single application but this time there were more than one pieces interacting.

We knew that there was a web application where the user could request a quote which would be calculated offline and then an email sent to them when it was ready to view.

That led us to believe that there was probably some sort of queue being used to store the outstanding requests and there’d probably be some sort of application processing the requests.

As it turned out the design of the system actually looked like the diagram on the right with the database effectively as a queue.

We then needed to work out which tables we had to read from/write to so that we’d be able to just replace the 'polling application' and leave the 'web application' alone.

We were then able to come up with a design whereby we isolated any interaction with the database into a 'bridging application' which then farmed requests out to a new application which we could scale horizontally.

It could also take care of writing the quotes back into the database so the existing application could read them back onto the screen.

Although we ended up not using this architecture for other reasons I think it’s a neat way of looking at systems to work out how we can change them with minimal impact.