I had the chance to present CQRS to the local .NET user group this week. The speaker had a last minute conflict so I volunteered to step up and speak. I only had a few hours to prepare. So what did I do? I had previously watched several of Udi's CQRS presentations—one in Australia the other in London. I really like Udi's style and the way he communicates his message, so I took (stole) the most basic elements and watered them down for a 30-minute presentation. »
When working on a new domain model a few days ago, we ran into an interesting issue. What happens when an aggregate has shared data? You know, data that is common or shared between aggregate roots? This is a question that also recently came up on the Domain Driven Design Yahoo Group, we had generally the same question but independent of the Yahoo Group.
For purposes of example, we will use the canonical sales/order model. »
I will be giving a free presentation tonight at 6:00 PM on CQRS. I'm going to give some historical background on CQRS and I will show how it resolves a lot of the pain and friction that developers experience when building systems. Further, I'm going to talk about how it can be used to scale a system out to 10,000+ transactions per second. Again, the event is free and there will be pizza provided. »
A problem that we experienced recently was that of dealing with and wrapping lookup tables. By definition, a domain model is supposed to be isolated from the outside world. It shouldn't have any concept of data access or persistence. Because a domain model is isolated and we don't want to inject services or objects into our domain object, how do we go about querying lookup tables?
In our particular domain, we have about a dozen industry-mandated lookup tables that we query 30+ times in various ways. »
Mark Harris recently recorded Udi Dahan talking about CQRS when he was at a user group in Australia.
It's about 90 minutes long, but if you're trying to wrap your head around CQRS, it's a great place to start.
One other note, Udi's style is independent of "event sourcing" as a mechanism for storing and rehydrating your objects from persistence. »
It might just be me, but every single time I see/hear the the acronym DRY used on a blog/podcast, it is always followed by: "(Don't Repeat Yourself)".
Does this strike you as ironic? »
Yesterday I did a massive post about separating HTML layout from user data and then using a JavaScript templating engine to bind up JSON data object which contains user-specific information. I also talked about setting the HTTP expiration policy on the HTML files and using CDNs to scale out your web tier without lots of additional hardware.
In thinking about the solution a little bit further it occurred to me that this could facilitate a RESTful layout of both HTML and JSON URLs. »
I've been working with CQRS for almost a year. Ever since I first heard about it, I was immediately convinced that it had the ability to vastly simplify a lot of unnecessary development overhead. In this particular post, I will not be discussing event sourcing which is often mingled with CQRS. Instead, I will be focusing on the query side of the equation.
Please note that the ideas contained herein are merely conjectures of what might be rather than any kind of working, concrete implementation. »
Jimmy Bogard recently tweeted that Persistence Ignorance does not apply to the ActiveRecord pattern. I couldn't agree more because ActiveRecord is about creating a strong coupling to the database schema.
Persistence Ignorance is about keeping your business objects ignorant of the underlying mechanism used to persist them and the schema in which they are persisted. In the case of ActiveRecord, it doesn't apply because these objects are intimately coupled to the schema itself. »
One of the things that I love about CQRS is that it completely eliminates the impedance mismatch that you normally experience with traditional ORMs. It is incredibly compelling to be able query and retrieve all values necessary for a particular report or screen in a single database call because of a denormalized database schema.
Over the past year there has been significant debate regarding Microsoft's LINQ to SQL, Entity Framework, and ADO. »