CQRS – Here, There be Dragons

I’ve been looking at CQRS a lot recently, whether through the blogs of Udi Dahan and Greg Young, podcasts like the Distributed Podcast, or videos on Vimeo, and all sorts of material on CqrsInfo.com. I’m trying to learn as much as possible about it because I feel it has many benefits but with the caveat that it requires careful consideration about when and where to apply it. Everywhere you turn to on the internet seems to be pushing CQRS as the answer to all our problems with frameworks popping up all over. In truth, I think whilst each individual component part looks so simple to comprehend, when taken as a whole, there is a lot more complexity for the “average” development team than any traditional N-tier approach they already know.

It’s easy to get swept away on the tide (I’m looking at myself here) as everyone gets excited and starts going down the CQRS road. I’m writing this so I can come back and reign myself in when I feel I’m edging towards making something more complex than I ought to. I aim to keep learning as much about it as possible so I can make the right decisions at the right time but I need a voice of reason nagging me to ensure I don’t get carried away. Don’t get me wrong, there are some very useful ideas in CQRS that could be used without going all the way and then there are some that 90% of the time you just won’t need like Event Sourcing (even though technically ES is not part of CQRS anyway but everyone writes as though it is).

All I’m saying is that whilst there’s a lot to learn and love about CQRS, do it with a cool head. We can’t all be as clever as Udi or Greg. We should be careful when deciding that CQRS solves our current set of problems that we aren’t trading those for a new set that we’re considerably less experienced at solving.

Advertisements
CQRS – Here, There be Dragons

Handling Multitenancy with Castle Windsor – Part 1

At my new job, we have an e-commerce app. It’s your typical online shop. Unlike most though, it is for specific commercial customers to use, each of which has their own business rules and our app tries to cater for it. Unfortunately, it doesn’t do a great job of this. Thinking about it, multi-tenant applications seem like a hard problem to solve without resorting to lots of “if-else” tests, etc. but that’s where tools like Castle Windsor really shine.

If you’re familiar with IoC (inversion of control) containers in general, you’ll understand how they resolve dependencies for you to build an object graph ready to use. Of course, Windsor does this too but it also provides some interfaces that help us control that resolving behaviour. Specifically, I’m talking about the IHandlerSelector interface.

IHandlerSelector allows you to plug-in to the resolving process and provide a means to influence which implementation of your registered interface should be returned by Windsor. As an example, imagine your service layer contains some kind of controller. By providing an implementation of IHandlerSelector that knows about the controller’s interface you could check the role of the logged in user and if applicable return an admin version of the controller otherwise return the ordinary and more restricted controller, all of which requires no conditional checks in the calling code. Or how about a controller with a method, say, PlaceOrder(). Maybe there are different rules to consider when CompanyA is logged in and calls PlaceOrder() compared to when CompanyB is logged in. All we have to do is provide an implementation of IHandlerSelector that determines the company that is logged in and return the appropriate controller. Yes, you need two (or more) implementations of the controller but at least we’re conforming to the Open/Closed principle and thus reducing the bloat that the alternative of one fat controller gives us not to mention the increased risk of bugs every time we have to go in and change it.

So what does an implementation look like?

Here’s our controller interface:

public interface IOrderController
{
    void PlaceOrder();
}

Let’s say we have two implementations (not shown here but not hard to imagine), one for each customer that do things differently when placing orders.

How does Windsor know which one to instantiate at the point it tries to resolve our object graph? Like this:

public class OrderControllerHandlerSelector : IHandlerSelector
{
    public bool HasOpinionAbout(string key, Type service)
    {
        return service == typeof(IOrderController);
    }

    public IHandler SelectHandler(string key, Type service, IHandler[] handlers)
    {
        var user = HttpContext.Current.User;

        if(user.IsInRole("SomeRoleThatIdentifiesCompanyA"))
            return handlers.Where(x => x.ComponentModel
               .Implementation == typeof (CompanyAController)).First();

        return handlers.Where(x => x.ComponentModel
               .Implementation == typeof(CompanyBController)).First();
    }
}

The implemenation is trivial. The HasOpinionAbout method tells Windsor that this class is interested in deciding which IOrderController to return, whilst the SelectHandler method makes the actual decision.

Now all we have to do is register our class with the container:

WindsorContainer _container = new WindsorContainer();
_container.Kernel.AddHandlerSelector(new OrderControllerHandlerSelector());

In my opinion, this is a great way to keep our code clean and nicely separated. If we gain a new customer and things are slightly different for that customer too, all we need do is provide a new IOrderController implementation and update our OrderControllerHandlerSelector class meaning we never have to touch our other implementations. OCP for the win!

Handling Multitenancy with Castle Windsor – Part 1