Infrastructure Ignorance

time to read 2 min | 350 words

Recently there have been a long discussion in the ALT.Net mailing list about Auto Mocking Containers. We covered a lot of ground there and it is interesting to boot.

What I wanted to talk about comes from this discussion. A while ago there was a big stick about Persistence Ignorance. I won't reiterate the arguments, but I want to expand the idea to other concepts as well. It is not just persistence that your code should be ignorant of, it is all the infrastructure concerns in general.

I don't care how good your infrastructure code is, it is still nasty pitfall of technicalities. I know that all of mine have been this way.

The IoC container that you use shouldn't appear anywhere in your code, nor should the persistence concerns mix themselves with the actual code. Invasive approaches, no matter what they do, should be frowned on.

A lot of people thinks that the model below is a good one to follow:


Personally, I think that it putting too much emphasis on the infrastructure. The infrastructure should not sit at the heart of the application. It should be shoved to some misbegotten corner and only see the light of day if there is no other choice.

The diagram below demonstrate how I think it should be.


There should be a lot more weight for the actual application code than the infrastructure code, and only at well defined locations will you have domain services call down to the infrastructure. In fact, I would like to isolate that as much as possible. Dependency Injection, AOP and minor amount of wrapping should allow you to get an application that is infrastructure ignorance.

The immediate result of which is that you get a lot more focus on actual business value than on implemented two phase commit using FAT12 file system.

That is not to say that infrastructure is not important, it is critically important. But the infrastructure should not be invasive.