This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Is unification a good thing?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
If you haven't been following Ralf's recent flurry of posts, I suggest you block out some time for it - it's well worth while. One of the questions that I continue to struggle with when reading his posts is how much do we gain, and lose, by creating a unified model. For instance, a given link between two software entities (holons) can have different properties - sync/async, one-way/duplex/request-response, stack-based/message-based, etc. By focusing on the relationships, instead of their properties, maybe we can discover insights that cross technological boundaries. On the other hand, does the loss of fidelity somehow hide critical details that impact system-wide understanding? I think that both of the above statements are true - fractals within fractals. A good OO design divides responsibilities up between classes in such a way that high cohesion and low coupling are achieved. The same could be said of service oriented architectures. It is ALL about getting the boundaries right. I think that in SOAs if we limit the types of communication between services to be async-only and message-based, in essence only allowing one-way or duplex message-exchange patterns, the resulting boundaries create services which are more loosely-coupled. From my experience, we get autonomous services - services that are loosely coupled in time as well. So, is the unified model a help or a hindrance? I think it helps, as long as we don't make the unified model the only model....
Previous Topic
