Consumer Driven Contracts

A while back a reader sent me an email asking about consumer driven contracts and how they fit into my stance on SOA. I'd intended to share my thoughts on the approach with the rest of my readers but alas it slipped my mind. Better late than never though, so I thought I'd take the opportunity to discuss the concept now.

Consumer driven contracts as an approach is intended to provide inputs into the service provider's contract design to ensure relevance, as well as provide constraints on how a service provider's contract can evolve over time such that compatibility is maintained with consumers.

However the intention should always be that the service provider contract evolves in such a way as to better express the concepts of the provider. We don't want to reduce the semantic fidelity of communications with our services.

I would say that as long as you're sticking mainly to publish-subscribe messaging (that is, avoiding command messages), then the needs of the consumer are considerably less relevant. Consumers are only informed of events as they happen. Command messages produce a subtle form of coupling where the service consumer instructs the service provider what to do.

Services that publish events do not prescribe or assume what subscribed services will do (if anything) once a notification message is received. An event message describes only an event that occurred within a service. The subscribers should really have no influence on this. As such, they should not be influencing the schema of the event messages published by the service provider.

So when using publish-subscribe messaging, I would suggest that consumer contracts are useful only in providing constraints on what can be changed in the service provider's contract in order to maintain compatibility with its consumers.

That being said, service contracts tend to be quite stable with process-centric self-contained service models - so I've not personally found consumer driven contracts worth the effort.

Consumer driven contracts really come into their own with data-centric contracts and centralised data architectures. When we always need to go and get our data from elsewhere, and all our service consumers use that data for different purposes, consumers have a substantial dependency on the service provider's schema. They will likely need to influence the provider's schema quite regularly. That in turn will affect the other consumers.

This is yet another reason to pursue process-centric service contracts with decentralised data architectures. It keeps your service contracts stable by virtue of minimising dependencies between service providers and consumers. You can read more about service contract stability here.