Domain Specific Reference Architectures

Many big vendors have invested a lot on blue print or reference architectures.  I came across another in recent months.  I witnessed a vendor team moving from client to client implementing this reference architecture as part of their SOA solution.
What were they actually doing? They were mapping the client’s domain to the reference architecture domain and thereby identified reference architecture services that supported the client’s needs.  This most probably works for some people.   But I feel uncomfortable with it because…

  • It means translating from one domain to another and back again.  It’s like having one massive bounded context around the reference architecture with a gigantic set of adaptors and transformers.
  • There is a very real possibility of semantic impedance on the boundary of the two domains.
  • There is likely to be two domain vocabularies or one large polluted vocabulary with synonyms, etc.

There are other reasons but these few are just old problems and habits coming back again.  Things that we accepted as dangerous and limits success in creating good software.

So, are reference architectures bad? Yes and no.  Maybe you should consider adopting its domain vocabulary as a first step.  A reference architecture with a rich metamodel is more likely to be more valuable than one without a metamodel.

And the moment you start thinking at a meta level, then you’re moving into a higher level of abstraction.  In this higher level, you will have a greater opportunity to describe your intentions agnostic of the reference architecture and the vendor’s technology stack.

The way I see it, services are defined at a meta level.  They describe your intentions and are independent of a reference architecture.  However, if you chose a reference architecture up front, then describe your intentions in the vocabulary of the reference architecture.

Does this make sense?  Because I’m just hypothesising here.

2 thoughts on “Domain Specific Reference Architectures

  1. I am not sure I follow – you seem to be saying that on the one hand using a reference arch can pollute your vocab, and on the other that adopting its vocab helps you to think at higher abstractions…?

    • Hi Kevin,
      That’s not what I said at all. You can end up with a polluted vocabulary if you use your vocab with that of the reference arch. It’s easy to end up with subtle differences and false synonyms because of the inter-domain mapping that will have to happen.
      Secondly, vocabulary does not help you work at higher level of abstraction. It is better to work at a higher level of abstraction if the reference architecture has a flexible meta-model. So, when you are at the meta-level you are immediately free of the reference architecture, because you can use the meta-model to create any domain architecture including the one from which you derived the meta-model. Basically, your meta-model can be the unifying thing between your domain and the reference architecture.
      Thirdly, if you commit to using the reference architecture and decide to describe your intentions, it is better to create these in the language of the reference architecture. Essentially, you abandon your language.
      The two key points here are (a) ubiquitous language = one vocabulary and (b) meta-model for bridging similarly close domain models is powerful because it will facilitate cross model transformations.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s