Diego Pacheco Tech blog

Service contract design is hard. People do it all the time, but it is not always correct. Most of the time, engineers pay more attention to the service's internal implementation than the contract. A Service contract is the most important part of a service. A good contract provides an abstraction that allows us to have flexibility and allow future refactoring without impacting clients. Being able to refactor code without breaking consumers is pure gold. It's priceless. Not all industries are the same; however, the more dynamic and agile the industry is, the more you need to be able to do Refactoring. To do refactoring more often, you need to make decisions that allow refactoring to happen at a lower cost. If the price of refactoring is always high, no refactoring will happen, and that is game over; that is how we create inadequate legacy systems. A service contract provides a high level of abstraction(ideally) or might(if they do a poor job) leak internal implementation details....

One of the most important aspect of a SOA approach is testing. In order to get this right you should have several levels of tests, is very hard to match all things you should have just with unit tests. If you think on abstractions a Service in Service Orientation(SO) it`s a composed by a service implementation and a contract. A service could implement multiples contracts. I like to have one contract per service but there are scenarios where you could like to have more than one, for service aggregates or domain segregation cases. So whats is a contract? For SOA contract is DATA, thats the real contract, but this could be seeing as many things, so i like to thing in some things to define what is the contract.  SOA is about Design so this could change depending of your main architecture design but in the way that i see it a contract would composed by the following elements.