robashton · September 27, 2011 11:37
diff --git a/cqrs.txt b/cqrs.txt
 CQRS is not complicated - complex architectures are complicated, and they're complicated because we make them complicated
 -------------------

 CQRS is not a complicated architecture, CQRS just means maintaining a healthy division of responsibilities between reads and writes across your system - that is, having the reads in your system executed in a thin clean manner appropriate to the views you want to retrieve, and your writes going through all the crazy logic you need such as validation, updating queues, third party systems, processing business rules - whatever.

 CQRS can be achieved by using a document database like Raven or Couch - using your documents as a write store, using your indexes as a query store. It can be achieved with your favourite ORM (Even better if you can actually use that O and that M and get some good old OO going) - if you want to use your objects for encapsulating business logic and go directly to the the queries to project the data you need for views (HQL, SQL directly, SPROCS, whatever) - from the same database even, providing this remains efficient enough for your needs.

 Of course you may well end up with two databases anyway, as trying to query a database comprised of tables that represent state in your "objects" can be pretty inefficient, with the read store updated from the write store using hooks in your write system to generate pre-calculated views or data that's more applicable to generating views - this is not a bad model and can work too, it's still CQRS.

 CQRS gets the "complicated" label because people often associate it directly with event sourcing, which requires that little bit more of up-front development in order to get the level of elegance you won't find in the above scenarios. However, even event sourcing is really simple once you look at it - and is a natural progression from some of the other ways of "doing" CQRS - which can be a bit muddy (not that there is anything wrong with systems that are a bit muddy). Note that I'm not mentioning DDD here At All - which is where a lot more of the learning lies.

 Consider hooking those events in your system to manually flatten/re-arrange data into other stores as outlined above? Does that work for that one other store? How about a reporting store? How about full text search? What about integration with third party systems and the data they want to see from you? How about the boardroom reports your CEO now wants on his desk each morning before he starts his day? 

 Deciding your single source of truth is the already written state gives you a certain amount of inflexibility, which you may or may not be happy with - because updating other views of this truth after small changes can be inefficient, generating other views of this truth after small changes can also be awkward - and recovering after introducing any write bugs to the system can be expensive in terms of cost and complexity. Hell - changing your object model can also be expensive as database migrations are hardly the easiest things if you're trying to work with pre-computed state and trying to somehow maintain that valid state in the new format.

 Moving to events and jumping through a few hoops to make this possible can open up a world of simplicity, and if it's not for you there are other options open to you. CQRS is not complicated - trying to shoehorn the responsibilities of read and write through a single model is complicated. Most of us realise that going through a standard "BLL, DAL, BOL, TLA, CRA, P) layer for both reads/writes is dumb, and CQRS is a good way of formalising this knowledge.
	CQRS is not complicated - complex architectures are complicated, and they're complicated because we make them complicated
	-------------------

	CQRS is not a complicated architecture, CQRS just means maintaining a healthy division of responsibilities between reads and writes across your system - that is, having the reads in your system executed in a thin clean manner appropriate to the views you want to retrieve, and your writes going through all the crazy logic you need such as validation, updating queues, third party systems, processing business rules - whatever.

	CQRS can be achieved by using a document database like Raven or Couch - using your documents as a write store, using your indexes as a query store. It can be achieved with your favourite ORM (Even better if you can actually use that O and that M and get some good old OO going) - if you want to use your objects for encapsulating business logic and go directly to the the queries to project the data you need for views (HQL, SQL directly, SPROCS, whatever) - from the same database even, providing this remains efficient enough for your needs.

	Of course you may well end up with two databases anyway, as trying to query a database comprised of tables that represent state in your "objects" can be pretty inefficient, with the read store updated from the write store using hooks in your write system to generate pre-calculated views or data that's more applicable to generating views - this is not a bad model and can work too, it's still CQRS.

	CQRS gets the "complicated" label because people often associate it directly with event sourcing, which requires that little bit more of up-front development in order to get the level of elegance you won't find in the above scenarios. However, even event sourcing is really simple once you look at it - and is a natural progression from some of the other ways of "doing" CQRS - which can be a bit muddy (not that there is anything wrong with systems that are a bit muddy). Note that I'm not mentioning DDD here At All - which is where a lot more of the learning lies.

	Consider hooking those events in your system to manually flatten/re-arrange data into other stores as outlined above? Does that work for that one other store? How about a reporting store? How about full text search? What about integration with third party systems and the data they want to see from you? How about the boardroom reports your CEO now wants on his desk each morning before he starts his day?

	Deciding your single source of truth is the already written state gives you a certain amount of inflexibility, which you may or may not be happy with - because updating other views of this truth after small changes can be inefficient, generating other views of this truth after small changes can also be awkward - and recovering after introducing any write bugs to the system can be expensive in terms of cost and complexity. Hell - changing your object model can also be expensive as database migrations are hardly the easiest things if you're trying to work with pre-computed state and trying to somehow maintain that valid state in the new format.

	Moving to events and jumping through a few hoops to make this possible can open up a world of simplicity, and if it's not for you there are other options open to you. CQRS is not complicated - trying to shoehorn the responsibilities of read and write through a single model is complicated. Most of us realise that going through a standard "BLL, DAL, BOL, TLA, CRA, P) layer for both reads/writes is dumb, and CQRS is a good way of formalising this knowledge.