SOA/MSA design - Isolating contract dependencies

Contract is a crucial part of any services anatomy. In a SOA/MSA approach, contracts exposes the services behaviour that consumers will rely on. This behaviour is usually exposed as series of interfaces and input/output structures and implemented by internal components. The last is usually hidden from external consumers. The previous described structure may look like this:

On this example, modules are splitted, there is only one dependency flow (internal modules doesn't know external ones), each module has Its own set of dependencies, consumers rely on abstractions (the contract), so far so good.
When consuming services through REST or SOAP, consumers will need to serialise and deserialise the structures service exposes. It means they will need to hold a copy of these structures locally in order to get this job done. Now lets say you want to avoid this structure replication through all consumers inside your company. Considering services are built following the structure illustrated before, the contract module could be splitted apart and then shared with the consumers. In this scenario, you may get ride of the structure replication issue, but will running into another. When issuing the contract module as is to consumers, they will now depend on the same libraries that contract depends, otherwise consumers wont be able to use them. What about services moving to a different library-A version that isn't compatible with previous ones? A scenario like this:

If all consumers don't upgrade to the same library-A version than service is they will be broken. More consumers you have on this model, more synchronisation between them will be needed to deploy. More services you have worst It get. The expected agility when choosing this architecture approach will be harder to achieve.
One possible solution for this problem is, accept that consumers will hold local copies and just deal with It. Accepting they will have some extra work is still better than the coupling scenario described before.
You can also design your service keeping the contract module with less dependencies as possible. It may looks like this:

This design guideline can increase services flexibility when sharing contract as library. Consumers would need be affected only contract behaviour changes.even here but there are techniques to mitigate these effects. It is also an example that being succeed on going for SOA/MSA approaches depends also on good design and architectures choices.

SOA - Dealing with Consumers Requirements

Services are created to be consumed. In case a Service isn't good enough (does not provide enough value), It fails on Its primary reason to exist. This makes sense for most of the companies I know and It is not different when talking about SOA. The goal of this post isn't advocate about SOA itself or disvantages/advantages of this Architectural Style. The idea  is highlight the consequences of drive Services requirements based only on consumers needs.

What is a Service?

It is a high level abstractions exposed as a business functionality to be consumed. By mentioning "high level abstraction", I mean, It should shape a business functionality as It really is (how It behaves). Low level details like  protocols, security, infrastructure, specific data consumer structures should  be out of the scope here.
Some of the ideas behind this definition are:

1. If business change, Service needs to change quickly - The advantage of dealing with high level business abstractions is because Service will need to change only the when business behaviour changess and not other layers. By avoiding introducing low level details on the Service design, you'll be able to respond quickly to business changes than doing the opposite.
2. Stay aligned with Business Strategies - That means, if companies wants to be able to consider expose business functionality for different consumers/medias/plataforms or compose several services to create  new business functionality, for instance, Service design should support It.

Dealing with Consumers Requirements

During the development life cycle, there will be cases where might be easier accommodate modifications on Services side in order to attend specifc consumer needs. By following this approach, you are creating a coupling on the Services design that isn't desirable. Services may looses It's capacity to quickly respond to changes without affect It's consumers.

Consider  a Sales Service that returns alls sales for a given Customer. Lets say there is a consumer (an UI) that needs display the sales in a specific order, different than the one returned by the Sales Service. For the UI point of view, would be easier have the sales returned on the order It needs. It may advocates the Service is much closer to the data. So ordering information there would be faster than iterating the sales  again on  the UI side and order the data as It needs.  

But now, lets consider the same services needs to be consumed by another API. What about this API needs the same information in a different order than UI?  

See, consumers driven  decisions increases the coupling by making Services harder to change without breaking other consumers. Services loose the capacity to quickly respond to business changes on these cases

Conclusion

The "sorting" example may looks a bit silly, maybe yes.. but consequences are the same when changing contract data structures/behaviour just to make consumer's life easier. So, be cautious when dealing with consumers driven requirements.  To avoid It, make your services Consumers Agnostic by avoiding  consumer specific requirements fall into the your Service design.