The document discusses consumer-driven contracts in software development, emphasizing the benefits of efficient API design and collaboration between consumers and providers to create robust contracts. It outlines the process of establishing and updating APIs along with the importance of automated testing and validation. Additionally, it acknowledges challenges such as managing large teams, onboarding developers, and maintaining clear documentation while suggesting frameworks and guidelines for successfully implementing consumer-driven contracts.

1. Consumer Driven Contracts
Qaiser Mazhar

2. $ whoami
● Scrum Master for Baskets & Checkouts
● Joined M&S in March
Previous Life
● Tech Lead & Agile Coach at Rightmove.co.uk
● Search Replacement (Odin)
● Property Data
● Helping other teams and individuals become more “agile”

3. Odin
● Microservices
○ Restful API, JSON over http
○ Java 8, Springboot
○ High quality, clean code
○ Healthy coverage (we did not chase percentage) - Spock, Wiremock, Mockito, AssertJ, Rest-
assured, Gatling, Spring Integration/Web-Integration etc...
○ ELK
○ Monitoring - Xymon, Dashing.io, Spring Health/Metrics, NewRelic
○ Resilience - Hystrix, 3 Site Architecture, Load Balancer
○ ...
● Frontend
○ Mobile first
○ Hand built components
○ Non-isomorphic

4. Odin
● High performing team
○ Autonomy
○ Support what we built
○ Right tool for the job
○ Clear standards and best practices
■ Living documents
○ Strong opinions, loosely held
○ All the DDs (ATDD, BDD, TDD, DDD)
○ CI/CD
○ Promiscuous Pragmatic Pair Programming
○ Sociocratic decision making process

5. Odin
● Challenges
○ Large Team (~12 Devs, 2 QAs, Team Lead, Tech Lead)
○ Lots of learning
■ It's ok to fail as long as there are learnings
○ Lots to do
■ Rearchitecture, CD, Mobile first responsive UI, Agile practices
○ Onboarding new developers
■ Better documentation?
○ Supporting non-CD Teams
○ Breaking changes in APIs

6. Consumer Driven Contracts
● Traditional end to end Tests (Dependency driven)
○ Too late to get feedback
○ Expensive to change so late
○ Difficult to orchestrate
■ Your client might not exist yet
○ Don’t know who is using your software
● Consumer Driven
○ APIs that provide value (and be beautiful )
○ Fail fast
○ Confidence in decommissions
○ Independent deployments
○ Improve communication/collaboration with dependent teams

7. How does it work?
● Centralised contract storage
○ Publish contracts each build
○ Golden source of client dependencies
○ Download and test each build
○ Test both consumer and provider against contract
● A Service can be both provider and consumer
● Frameworks can help:
○ Realestate.com.au pact
○ Thoughtworks pacto
● Stub Provider Service
○ Testing service not downstream
○ Spring @Profile annotation

8. Creating a new endpoint
1. Consumer identifies a need from a provider that is currently not available.
2. Consumer collaborates with service provider to define API to satisfy consumer’s
needs whilst considering the constraints and considerations of the provider.
Result is a contract that the provider must abide by.
3. Provider implements the API to honour the contract, whilst still satisfying all
other existing contracts.
4. Provider runs an automated test to verify the contract has been satisfied as far as
the API is concerned. Functionality is tested via Unit, Integration and other
appropriate tests.
5. Provider publishes changes.
6. Consumer publishes contract and consumes new provider API.

9. Creating a new endpoint
Consumer ProducerPACT
Consumer ProducerPACT
Consumer ProducerPACT

10. Updating existing endpoint
1. Consumer identifies a change to an existing endpoint for a provider.
2. Consumer collaborates with service provider and any other existing consumers to define API that
will satisfy all consumer’s needs whilst considering the constraints and considerations of the
provider. Result is a contract that the provider must abide by.
3. Provider implements the API to honour the contract, whilst still satisfying all other existing
contracts.
4. Provider runs an automated test to verify the contract has been satisfied as far as the API is
concerned. Functionality is tested via Unit, Integration and other appropriate tests.
5. Provider publishes changes.
6. Consumer publishes new contract, removes old redundant contract and consumes updated
provider API.
7. Remaining consumers publish new contracts, remove redundant contracts and consume updated
provider API.
8. Provider removes deprecated API.

11. Updating existing endpoint
Consumer ProducerPACT
Consumer ProducerPACT
Consumer ProducerPACT
Consumer ProducerPACT

12. Too much of a good thing..
● CDCs has most value when working with other teams with independent release
cycles
○ Limited when all consumers ever are in the same small team
● Overhead when rapidly changing API
● Single point of failure for CDC Repository
○ Pick somewhere robust - nexus?
● CDCs can be abused
○ Too loose of a contract
○ Not updated
○ Testing returned values
● CDCs enable conversations, not replace

13. Other Stuff
● Postels Law
● API Versioning
○ Keep only a couple API versions and clean them up
○ Contract with Consumers that only N versions will be supported so they must update regularly
● Rollbacks are more robust
● Discover and Test APIs
○ Swagger/Spring fox
○ README.md
○ Be consistent - don’t make me think