Posts Tagged ‘Software Architecture’

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.

User-friendly concurrency handling in occasionally disconnected systems

February 1, 2010

Recently i was in a hurry to grab some reading material and i accidently pulled out a book I’ve mentioned previously. David Platt’s “Why Software Sucks” is full of thoughts on how software could be made more user-friendly. One of his points is that users should not have to understand the internal workings of a computer or the particular piece of software, they are trying to use.

Reading this again made me absolutely sure we had come to the right decision in a recent discussion on how to deal with concurrency in an “occasionally disconnected” client / server system.


Making Roles Explicit

June 29, 2009

Commenting on my previous post, Udi Dahan brought this talk of his to my attention:

While I do feel that some of the points I made with regards to persistence are still valid, I did find Udi’s presentation extremely interesting. The example of IValidate<Customer> just feels right. If you have an interest in software architecture, I am sure you will find this interesting.