Take the 2-minute tour ×

I have a Context object. Its a complex little character that composes an Auth object, a CurrentNode object, a Graph object, and some others. The Context object has numerous simple methods such as isLoggedIn() and isAdmin(), and many more complex ones such as hasPathToNode() and netPathsToNode(). Mostly these methods simply proxy to the attached objects.

The Context object is in my Domain layer, ie. the bottom of my application stack. It is used by all layer super types including Controller, View and Services. This seems to be working quite well.

So far I have not needed to make other domain objects dependent on the Context. My controllers or services have been able to decide if a requested action should go ahead. Now, however, I have a domain object that is particularly complex and heavily reliant on the logic encapsulated within the Context.

I can go ahead and let this domain object depend on it's Context, but my question is should I? The object is in the same layer as the Context, which is good. The Context is a singleton, but is resettable, so therefore easy enough to test.

According to Martin Fowler's POEAA discussion on the Service Layer Pattern, logic which is 'domain logic' (as opposed to 'application logic'/'workflow logic') belongs in the domain objects, so that encourages me to go ahead and let the dependency take place.

I realise that 'coupling' in general is a something to avoid. In this case, however, I would be replacing inter-layer coupling with intra-layer coupling, which I think is an improvement in itself. Eventually I would make the dependencies injectable, which would further reduce the downside of coupling.

It's a reasonably significant departure from my approach so far so I want find out what you think before I make the change. If I do go ahead with this dependency, I would probably refactor all the work I have done to date and let other domain objects depend on their Context too.

share|improve this question
It's easier to understand question if code is presented. –  MariuszS Apr 27 '13 at 9:51

2 Answers 2

up vote 2 down vote accepted

My view is that it all depends. You have to have a little pragmatism, or the "correct" solution can be 10 times more painful than the tightly coupled solution. Can you provide more information about the domain object which is relying upon the Context object? Is the reliance upon the Context object fundamental, or a special case? Perhaps features within Context need to be factored out to another class and shared with both? Perhaps you can provide some events on the Context object that the other class can hook into? In my view there's not enough information yet to make that call. There is no one size fits all solution to these kinds of problems.

share|improve this answer
Thanks David, your practical list of considerations was all I needed to get started in the right direction. –  Kim Prince May 6 '13 at 22:10
Thanks Kim, happy to answer any other questions. –  David Cummins May 6 '13 at 22:20

Without sample code and implementation, it is hard to determine whether should or not your domain to depend on the context. However, I have done the work with legacy code which has many-many static methods and contexts (such as configuration). I also did developed a class where it handles all the basic operation in WPF (such as menu bar and main tabbed panel). The result, all of them are hard to refactor, and takes a lot of time to re-deploy it to another application.

If available, I suggest to constructor injection the context interface (not the context itself) at the domain, either create a direct dependency. If it is hard to use / create, deploy a new layer which has the default static builder for it. Example:

public static class DomainContextCreator{
    public static Domain DefaultDomain{
            IContext context = new Context();
            Domain domain = new Domain(context);
            return domain;

As addition, you can always has a wrapper class to handle some context, such as static property, static method, etc; and make it injectable and general. You can found the example of the implementation at codereview here.

Maybe there will better answer if you provided your code implementation example.

share|improve this answer

Your Answer


