Thread by @odrotbohm

As this came up in my timeline again today, here's what I think is the gist of the problem I see with consumer-driven-contracts (#CDC). Thread…

1/ With #CDC you fundamentally establish a customer / supplier relationship in DDD strategic design terms with the API provider ending up as customer (downstream) and the client as supplier (upstream). That means you end up with *multiple* upstreams for a *single* downstream.

2/ This might sound counterintuitive first and like a detail but has important consequences: there's significant coordinating and disambiguation work this setup imposes on the API provider. *It* has to moderate potentially conflicting requirements. It serves multiple masters.

3/ It also has to know all clients, which causes the constant need for the individual parties to exchange, negotiate about potential changes etc. Mind you, we're talking about the party that encapsulates the crown jewels of your enterprise: business logic that makes you money.

4/ Why would you want to bring that party into such a defensive position? Remember, with microservices you architect for independent evolvability. If you set yourself up for constant negotiation, you completely subvert that goal.

5/ If you invert that relationship (provider driven contracts, PDC). The party that knows most about the domain implements it and defines the API. The server can produce stubs for the clients to easily test their usage of the API (via Spring Cloud Contract / Wiremock).

6/ Newly appearing clients are expected to conform to the API or raise requests so that the relationship evolves into customer / supplier. Not much technical difference but a significant organizational / political one.

Over and out. ✌️

Note, that this doesn't mean that tech like Spring Cloud Contract, PACT etc. is bad or anything. If you need to do #CDC, they're the absolute best way to tackle the problem. #SCC's #Wiremock integration is even uber helpful with PDC, too. It's not a tooling thing at all.