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.
Hy jonas
ReplyDeleteI would argue that if you apply true SOA style architecture as proposed by Udi Dahan, Bill Poole and many more in contrast to Thomas Erl SOA having a centralized domain model violates the four tenants of service oriented architecture. Because each individual service (by service I do not mean web service!) is the only owner of a certain business data other services can never have the same notion of the data so this leads to the conclusion that a shared domain model is per definition a design flaw.
But certainly it has a valid point there. For example infrastructure is deployed to multiple services which then introduces artifial coupling. BUT infrastructure doesn't need to evolve at the same pace. For example part of your common infrastructure is creating word 2010 documents. This library is deployed to service A and B. when service B need the ability to produce 2013 docs but service A doesn't (let's say the department which collaborates mainly with service A will not be upgraded because of some other legacy word plugin), service A could still reference V1.0 of the infrastructure lib and doesn't need to be redeployed. The most important point here is that you have to make explicit decisions
Sorry last comment got published anonymous. It was me :)
ReplyDelete@Daniel
ReplyDeleteI completely agree with your comment.
The point is, that in most projects I have been on this awareness was not there... at least not from the start.
I also think that if you embrace this fact, SOA gets a lot less attractive for many projects. (i.e. when the same team is responsible for all the services).
Of course you can develop shared infrastructure in a way that it can be deployed in different versions to different services. But it complicates your live a lot (technically compatibility, governance, maintenance ...). So you really should be sure that it is worth it ...
Yes indeed. As always every technology or architecture/style choice comes with its benefits but also disadvantages regarding maintainability, versioning etc. so there is no silver bullet.
ReplyDeleteBUT I see advantage in an architectural style which forces you to think about those kinds of questions early in your process. Often people don't do it and run into a lot of troubles afterwards. Regardless of you use the monolithic or distributed approach the questions to be asked are often the same. The answer can be different.
Applying true SOA style is hard for most teams. They don't want to leave their comfort zone of traditional RPC thinking. Also having multiple schemas/domain models in multiple databases scares people. Often I see also a huge force which draws people to more centralization. For example if you talk about a customer, developers usually see an entity type customer which ultimatively leads to centralized thinking. They fail to see that different business contexts have their own notion of a customer and their only common notion is a customer ID. So the data of a single customer resides in multiple schemas/databases with even possible redundancy. This freaks out most developers with strong database knowledge.
Another area is applying good commands and events which are purely business focused and not technical... Maybe we should do a usergroup about this topic, because I dom't want to hijack your blogpost :)
Daniel
@Daniel
ReplyDeleteHijacking is always welcome. Especially if the comments are as valuable as yours :-)
Just adding a quote from Dan North at GoTo Zurich:
ReplyDelete"DRY ist the enemy of decoupling."
https://twitter.com/xnka/status/322252783183093760