What I learnt, or my notes, from "In The Brain of Greg Young: CQRS and Event Sourcing - the Business Perspective"

gistfile1.txt

Notes based on Greg Young's business perspective presentation

http://skillsmatter.com/podcast/agile-testing/greg-young-cqrs-event-sourcing-the-business-perspective 

With a standard structural model we make assumptions of what the business may or may not want in the future. How can we presume to know what to track and what to discard.

CQRS/ES benefits:
* Captures behaviour explicitly, events carry the intent of users.
* We can derive any possible model about data that may be required.
* Allows domain experts and users to look at today in any way they may want to.
* Developers are unlikely to say "no, we can't do that because we didn't think to track that".
* We no longer need to reverse engineer intent in an ambiguos way.
* Three distinct development branches, allowing for cost effective resources.
* Lower skilled developers can design views and work on front-end tasks bcause read side is low-risk, highly specified boilerplate development. It can been outsourced without typical communication issues.
* Keep skilled developers working in the domain for complex business problem solving.
* Use developers with graph design and communication skills for the client facing side.
* Ability to scale out each section easily and independently because they don't step on each others toes.