Posts Tagged ‘cqrs’

CQRS: Really simple real life benefit

January 18, 2011

I got this real life question once again just recently:

“Could you show the name of the person who created each order in the list as well?” (domain changed to protect the innocent)

This question is a very basic, but very real, example of why I like the Command Query Responsibility Segregation (or CQRS) pattern.

With a datamodel that looks like the one above, the technical answer is usualy someting like: “Ok, how are we going to do this? Let’s put in a join to the User table. Then lets extend the order object with a display property (!!!) for the users name”. If the team is a little more trained you might hear something more along the lines of: “Ok so we’ll just specify in the query that the object mapper should load the user that’s associated with each order as well”. One is a little cleaner then the other, but both will most likely start to smell pretty quickly. Then somebody comes along and asks for a count of the items on each order and before you know it, your “FetchAllOrders” sql has balooned into some kind of monster join that no one but it’s mother can love (or figure out) and as an added bonus, performance goes south.

In a CQRS environment we have the priveledge of designing solutions like: “Sure, lets just store the user name in the viewmodel for the order list screen so it will be right there for clients to display. Also to make sure it’s kept up to date if it changes, let’s subscribe to the “UserRenamed” event.”.

And for the item count? Just subscribe to the “ItemAddedToOrder” and “ItemRemovedFromOrder” events and update “NumberOfItems” accordingly.

It just makes me feel all warm inside.


How to NOT inject services into entities (copycat title)

January 17, 2011

Working on my hobby poject I came across a familiar situation of having to interact with a (to my domain) external service. The service in this case is push notification. I know the “official” guidance is to not inject services (or anything else for that matter) into domain entities (I completely agree), but I was struggeling with how to follow this advice without breaking the incapsulation of my domain. The critical advice came from a blog post ( – see “Behavior methods”) by Jérémie Chassaing.

The techniques is familiar, but i’m surprised how perfectly in makes sence for these kinds of cases. My event handler ended up looking like this (domain has been substituted for a basic blog for the example):

public class PostChangeHandler : IHandle<PostAddedEvent>, IHandle<PostUpdatedEvent>
     ISessionFactory sessionFactory;
     ISubscriberNotificationService subscriberNotificationService;

     public PostChangeHandler(ISessionFactory sessionFactory, ISubscriberNotificationService subscriberNotificationService)
         this.sessionFactory = sessionFactory;
         this.subscriberNotificationService = subscriberNotificationService;

     void IHandle<CommentAddedEvent>.Handle(CommentAddedEvent domainEvent)

     void IHandle<CommentUpdatedEvent>.Handle(CommentUpdatedEvent domainEvent)

     private void NotifySubscribers(Guid postId)
         using (var s = sessionFactory.OpenSession())
         using (var tx = s.BeginTransaction())
             var post = s.Get<Post>(postId);


Command handlers are a great candidate for DI in my opinion. Leaving it up to the command/event handler to supply the service to use in the concrete case makes a lot of sense too. I find that the above leaves me with a domain that describes exactly what i want it to: “Who should be notified?” – all while abstracting away the concrete “How”.

Distributed Systems Podcast

December 22, 2010

I’m right now listening to the first episode of “Distributed Systems Podcast” – a brand new postcast by Andreas Öhlund, Jonathan Matheus, Jonathan Oliver and Rinat Abdullin.

If your following the CQRS/DDD google group (also very recommendable) you allready saw this, but in case you diden, it shows lots of promise. So there’s your “head’s up” 🙂

Go check it out: