Where trying to improve the "confidence" we have in our inter-service communication.
Background: "Contracts" has been a matter of sharing a piece of code that defines an interface to implement, but over the years, the shared code changed, and a lot of different implementations (soap, msmq, rest etc.) sprouted up, which could all be said to implement the same interface, but in no way plays well together, whithout mapping, which caused a forest of "mapping" microservices to be implemented, which again, appears in different version. Development and Operations are both suffering from this.
Intention: I would like to define contracts for the endpoints on the outside, using something like Swagger or API blueprint. With swagger i can compare the swagger.json "contract" with the swagger.json for the service claiming to implement it, and with API blueprint, theres "dredd". For MSMQ based transports, we'll need some other approach, but i think contracts for the structure inside the messages could/should be conformed to for the same reasons as the http-endpoints.
The details about how to verify is not the question - the question is: How would you organize these contracts? Should we have an internal repository of contracts that can never be changed, but only occur in new versions, and then have the verification-process be told which contracts are (supposedly) implemented? Said contract-repo should be read-accessible by our verification-process, and to our (and external) developers...
Any inputs regarding the problems described in the background is appreciated, maybe I'm looking the wrong way for a solution?