In today’s world of software development we deal a lot with integrations, SOA and Microservices pushed this to the next level and IoT will make developers life even more difficult and challenging. There is an approach to tackle integration hell, to decouple service development and to allow API to evolve. The approach is called Consumer-Driven Contracts. It allows consumer and provider to evolve and still compliant to agreed contract.

1. Consumer-Driven
Contracts
to enable API evolution
Izzet_Mustafayev@EPAM.com

2. ● proud father
● SA in EPAM Systems
● Java is my primary programming language
● exploring FP with Erlang/Elixir/Elm
● passionate about agile, clean code and devops

3. Agenda
● Problem Statement
● Solution
○ Patterns
○ What?
○ Why?
○ When?
○ How?
● Takeaways
● References
● Q&A

4. Problem
Statement

5. Dependencies...

6. Component Diagram

7. {
"party": "NYSE:EPAM",
"price": 85.29,
"change": {
"abs": 0.74,
"rel": 1.02
}
}
Phase 1
{
"party": "NYSE:EPAM",
"price": 85.29,
"marketCap": {
"value": 4.4,
"level": "B"
}
}
Phase 2

8. Monolith Case
- Interface verification fails early
- Modules share run-time

9. Microservices Case
- Independent run-times
- Wired by mean of exposed interfaces
- Transient dependencies
- Potentially different platforms
- Independent teams and lifecycles

10. Solution

11. Postel's law
https://en.m.wikipedia.org/wiki/Robustness_principle
- Architectural change
- No automated contract verification
- Obligations on both sides

12. Feature toggle
https://martinfowler.com/articles/feature-toggles.html
- Architectural change
- No automated contract verification
- Obligations on both sides
- Complexity on provider
- Security concerns

13. Parallel change
https://martinfowler.com/bliki/ParallelChange.html
- Architectural change
- No automated contract verification
- Obligations on both sides
- Complexity on provider

14. What?

15. Consumer-Driven
Contracts
https://martinfowler.com/articles/consumerDrivenContracts.html
- Process change
- Unlocks provider API evolution
- Automated contract verification
- Obligations on both sides

16. Why?
- Consumer drives usage of contract
- Consumer can be tested in isolation
- Provider has freedom to introduce changes*

17. https://www.thoughtworks.com/radar/techniques/consumer-driven-contract-testing

18. When?

19. CI/CD

20. Consumer & Provider

21. How?

22. Spring Cloud Contract
https://cloud.spring.io/spring-cloud-contract/
- Contract Verifier
- Stub generator + runner
- Starter for Spring Boot
- Java only*

23. Pact
https://docs.pact.io/
- Contract Verifier
- Stub generator + runner
- Polyglot (Java/Scala, Ruby, .Net, JS, Go, Swift)
- Pact Broker

24. Demo

25. Takeaways
- CDC is a TDD like way for integration problem
- CDC is about verifying that Consumer and Provider have a
shared understanding of their interaction
- In case of polyglot consider to use Pact
- For Java shop Spring Cloud Contract fits well
- There are means to share specifications (pact files)

26. References
- Consumer-Driven Contracts https://goo.gl/c3cqwV
- Pattern: Consumer-Driven Contracts https://goo.gl/vkTxgB
- Testing Strategies in μsvcs Architecture https://goo.gl/357tQ6
- Pact https://docs.pact.io/
- Spring Cloud Contract https://goo.gl/OgkZnl
- Demo source code https://github.com/webdizz/cdc-api-evolution

27. Q&A

28. Izzet_Mustafayev@EPAM.com
@webdizz webdizz
izzetmustafaiev
http://webdizz.name
Thanks