I would like to explain CQRS to my team of developers. I just can't figure out how to explain it in the simplest way so they can implement the pattern rapidly without any others frameworks. I've read a lot of resources including video and articles but I don't find how to implement CQRS without using others patterns like a service Bus, event sourcing pattern, domain driven design. I know the purpose of these pattern but for the first step, I don't want them to think CQRS and these patterns must be tied together.
My first idea is to say that CQRS is about separating the read part and the write part. The read part is composed only of the UI project, and DAL project. Then the write part is composed of a typical multilayer architecture: UI/BLL/DAL. Then, does CQRS say we must also have two datastore ? What about the notion of commands which reveal the user's intention, is it also something part of CQRS or DDD ?
Basically, how to implement CQRS without using others patterns. I concede it's also not that clear in my mind because I've used to work with NCQRS/DDD/Event Sourcing/ServiceBus in my personal project.
Best Answer
There are several ways of going about this. You know your team best. It's best to ask yourself at what level of abstraction you need to speak for them to comprehend.
Cqrs is really about seperating read logic from write logic. This is best explained by comparing it to todays layered architecture as promoted by database vendors (video section over on http://dddcqrs.com does a good job at that), mostly because people can relate to it and see how the changes you propose fit into that architecture. You could just stop at the argument that for the purpose of reading data there's no need to jump through all the hoops (of the write logic). No need to go any further (no seperate stores, ddd concepts, messaging, service bus, etc.). That said, there's much more value to be gained, both from a technical and functional perspective, if you pursue further. But again, 1 step at a time. Remember, people in general are not very fond of change (even if it's a good change). There's lots of value in the offspring of cqrs, but it requires careful judgement and assesment if it fits your team (and their maturity). Sometimes it's better to grow together than dragging people into something. Also, don't forget that management is not to be ignored either.