The No Dependency Architecture (NDA)

We already have many, many, many acronyms in our profession; TDD, BDD, DDD, SOA, EDA, DIP and SOLID just to name a few. So who am I to add yet another one in the mix, well I am a nobody. Having covered that, I would like to continue explaining this new one.

NDA is a software architecture that has no dependencies between the different components. It’s all in the name :)

By combining the Dependency Inversion Principle (DIP) and an Event Driven Architecture (EDA) we can achieve software that has no dependencies, not internal not external. So why would we want that? Well it enables you to just replace any part in your software solution with something else without it affecting the rest of the solution. And you will be able to scale the solution much easier.

So let’s look a bit more into the details, first I would like to start with DIP. Dependency Injection can be achieved using an Inversion of Control (IoC) container. An IoC container will provide an already instantiated object that (when done properly according to DIP) is based on an interface. The consumer of the object is only using the interface and does not know anything about the actual implementation.

One simple rule about how to provide the dependent objects is that when the consumer object cannot work without the dependent object it should be provided in the constructor of the consumer object; if the consumer object can continue without the dependent object (i.e. logging module) than that object should be provided via a setter property of the consumer object.

Modern IoC containers can Auto Wire the dependencies when creating an object, meaning that if a object of the requested type is present in the configuration you will not have to specify the dependent object in the constructor arguments of the consumer, this will be done automatically. I am a fan of keeping the configuration of the IoC container in a configuration file, this way I can easily provide a different implementation of the requested objects by just changing the configuration file. No need to recompile anything. I currently am working a lot with Castle Windsor which is a great IoC container.

So this should take care of dependencies your code may have between other parts of your code (i.e. object between object). Now we can move on to try and get rid of dependencies between different systems or major parts of your system (i.e. between services and consumers). When using an Event Driven Architecture your code is basically sending out events when something happens and does not care who or what is acting on those events. Different systems may subscribe to these events and may do their own thing. And to take this one step further you should consider using a service bus architecture, which basically means that events will be published into a cue. Consumers of these events subscribe to the cue and will get notified whenever there is an event waiting for them. There can be as many consumers subscribing to the events via the service bus as needed. The publisher does not know nor care about the consumers; it fires the event and moves on. Consumers don’t know or care about the source of the event, just that it is the type of event they are interested in.

As you can see this decouples the different systems from each other, since none of them know about each other there can be no dependencies between each other. Currently I am looking into NServiceBus, I got a real nice demo today from my college John that started this current thought process.

So now I believe we have a system that does not depend on anything, well realistically it depends on things, but these things can be switched, replaced, multiplied and even be offline nobody knows. I plan to go over these different parts in the coming posts, so if you have any comment I would love to hear from you.

Castle Windsor http://www.castleproject.org/container/index.html
NServiceBus http://www.nservicebus.com/