In his presentation "Designing For Rapid Release" (slides) Sam Newman points out an ugly fact that we often try to ignore: SOA and DRY are to a large extent opposed forces.
Of course this is not a new break-through discovery and I guess it is also nothing new for most battle-proven enterprise developers. But I also have the experience that in most SOA projects this topic is treated like the crazy uncle in the attic: You don't talk about it and you certainly don't plan for it.
The result is usually a schizophrenic feeling: The architecture postulates nice decoupling, but in reality we end up with the feeling that we are not doing it right: either we are using shared logic in several services which negates idea of decoupling or we have a lot of code duplication.
In the presentation Sam illustrated this conflict with two services that share a common domain model:
In the above picture, since service A and service B are both using a common model from a shared library, they get tightly coupled. On the other hand managing the development and releases of the shared library all of a sudden gets much more complicated under the premise that service A and service B should be decoupled.
He further brings the incompatibility of SOA and DRY to the point with the following quote:
Ending up with tightly bound services because of code-reuse is significantly worse than to copy & paste that code.
I like that Sam makes the conflict between SOA and DRY explicit. Not ignoring this fact is the first step to objectively balance the tradeoffs and to honestly plan how to deal with the drawbacks of either approach.
It's interesting to watch how the recent trend to mobile and browser applications is changing the traditional understanding of client-server separation and how the traditional territories of some technologies are blurring.
