Pundit feedback

woloski: I started to read this and I thought you were going to say that separating reads and writes lead to performance issues. I had to read it twice to understand that you were stating the opposite at the end of the paragraph. I would approach the beginning of this section differently. I like the quote but I would reinforce right away after the quote that you could verify that empirically. Maybe saying after the quote: "We witnessed the power of separating the reads and writes when we had to solve a performance issue"
Updated text.

woloski: So you would be confortable recommending the event store that was built for this project for others to use? If that's the case I recommend pointing to it (with the proper disclaimer)
Added comment about it not being production ready.

woloski: Can you add a specific example of when this happened or point to a chapter that talks abou it? I think it will be beneficial to the reader to understand what are those cases where you needed to understand how to work with eventual consistency
Added chapter references

woloski: again, an example comparing assumptions with what you found would be good
Added references

woloski: this is interesting... did you end up optimizing the bus to handle locally vs distributed? if that's the case can you point to the commit or the lines of code that shows where you are using two different buses and in which cases?
Expanded

woloski typo: bourne - born
Fixed

woloski: this sounds a little cliché :)
We're Ok with that...

woloski: This is a bold statement. People might read this wrongly. Not everyone associates TDD with a design activity. People might associate TDD with unit testing. So I would expect here a word about what testing technique you find more useful if unit testing wasn't (specflow?). Or if you were talking about designing "part of the system" I would be more specific about what is a "part of the system"
Re-written

woloski: I would expect more of these type of comments in the rest of the lessons learnt "Our assumption that events should only contain information about the change in the aggregate or the bounded context proved to be unhelpful: events can contain additional information that is useful to the subscriber and helps to reduce the amount of work that a subscriber must perform."
Adding additional links etc

woloski: another good paragraph

woloski: Good. I would emphasize on this: "We see this is a key reason why the CQRS pattern is not a top-level architecture". But would write it like "Through our journey we convinced ourselves why CQRS pattern..."
Changed

woloski: I didn't follow this paragraph. I would expect the second statement to be further details on why involving the domain expert is good in CQRS, or what CQRS brings to the table together with the domain expert. Maybe you wanted to say that in the second sentence but I would rephrase it.
Added missing sentences.

woloski: why? did you run the acceptance tests on a staged environments automatically before pusing to production? If that's the case I would write that here and point to the chapter where you explain how you did that.
Expanded.

woloski: These key questions are great! This should be copied to a chapter at the beginning of the journey. Kind of TL;DR for the book :)
Considering it...

woloski: This is good and honest. I think I said in one meeting "you should built on top of what is there already". Now, after reading this, my question is: would you use the infrastructure that you built for this project to build another CQRS module/bc/system not related to conferences? If the answer is yes, then you should point to your implementation as a way to start with a solid infrastructure.
No - this is answered below.

woloski: Sounds like process manager was central to the app. I am curious what would be the implementation order if you were to start again.
Not sure we have this.

woloski: this is interesting... are you talking about processing commands in the local machine instead of going to another worker? If that's the case I didn't follow how you would choose one or the other mutually exclusive. I thought "local execution of commands" was an optimization, so if you use only "local", if your app needs more scaling and you have to offload the web role how would you do that?
Clarifying

woloski: Would be good to point to the issues you've found during the perf tests
Added link