Re-added quotes and feedback from Grigori:

Pundit feedback

gmelnik: Here we should add a side bar of the conversation where Udi and Greg agree on the definition. I've extracted the following from the recording and I think we should place it verbatium (with Greg and Udi's permission of course!):Udi Dahan: If you are going to be looking at applying CQRS, it should be done within a specific bounded context, rather than at the whole system level, unless you are in a special case, when your entire system is just one single bounded context. Greg Young: I would absolutely agree to that statement. CQRS is not a top-level architecture. CQRS is something that happens at a much lower level, where your top level architecture is probably going to look more like SOA and EDA. Udi Dahan:That's an important distinction. And that's something that a lot of people who are looking to apply CQRS don't give enough attention to is just how important, on one hand, and how difficult, on other, it is to identify the correct bounded contexts or services, or whatever you call that top-level decomposition and the event-based synchronization between them.A lot of times, when discussing CQRS with clients, when I tell them "You don't need CQRS for that", their interpretation of that statement is that, in essence, they think that I'm telling them that they need to go back to N-tier type of architecture, when primarily I mean a 2-tier style of architecture is sufficient. And even when I say 2-tier, I don't necessarily mean that the 2nd tier needs to be a relational database. To a large extend, for a lot of systems, a NoSQL, document-style database would probably be sufficient with a single data management type tier operated on the client side. As an alternative to CQRS, it's important to lay out a bunch of other design styles or approaches, rather than it's been either you are doing N-tier ORM or CQRS. Question: Do you consider CQRS an approach or a pattern? If it's a pattern, what problem does it specifically solve? Greg Young: If we were to go by the definition that we have set up for CQRS a number of years ago, that's going to be a very simple low-level pattern. It's not even that interesting as a pattern, it's more just pretty conceptual stuff - you just separate. What's more interesting with it is what it enables. It's the *enabling* that the pattern provides that's interesting. Everybody gets really caught up in systems and they talk about how complicated CQRS is with service bus and all the other stuff they are doing, And in actuality, none of that is necessary. If you go with the simplest possible definition, it would be a pattern. But it's more what happens once you apply that pattern - the opportunities that you get.
I added this to Reference chapter 2 instead - I think it makes more sense there...

gmelnik: To learn more about the foundational principles of DDD, you should read the book "Domain-Driven Design: Tacling Complexity in the Heart of Software" by Eric Evans (2003) and to see how these principles apply to a concrete development project on the .NET platform with insights and experimentation, read the book "Applying Domain Driven Design and Patterns" by Jimmy Nillson (2006).
Updated

gmelnik: In addition, see how Evans's understanding of what works and what doesn't in DDD and how he conceptualizes and describes how it all has changed over 5 years, we recommend his talk at QCon London 2009 (http://domaindrivendesign.org/library/evans_2009_1).
Added

gmelnik: Call out: "Every effective DDD person is a Hands-on Modeller, including me" ~Eric Evans
Added

gmelnik: Call out: "Focus relentlessly on the core domain! Find the differentiator in your software - something significant!" ~ Eric Evans
Added

gmelnik: Domain Model - italicize just like other terms on the first use.
Done

gmelnik: Do we need to provide a definition of an Anti-Corruption Layer also? I think we use those in the code. An Anti-Corruption Layer is a gatekeeper to prevent non-domain concepts from leaking into the domain model. They help keep the model clean.
Added a bit further down.

gmelnik: Call out: I think context mapping is perhaps one thing in there that should be done on every project. The Context map helps you keep track of all the models you are using. ~Eric Evans
Added