Pundit feedback

gmelnik: We keep repeating the definitions of Command and Event in the Ch 5, 6, 7. Is it intentional?
Yes, they do vary slightly in the different chapters.

fsimonazzi: Would this be the diagram representing the "as of V2" or "new in V3" architecture? It has handlers and domain model on the web role, but it doesn't seem to publish events or commands.
Fixed

fsimonazzi: This is not accurate. The system saves all the commands generated by the process manager together with the process manager itself, in the same operation. Then it tries to dispatch the messages and remove them from the db as each command is sent.
Fixed

fsimonazzi: Essentially we're are relying on the fact that the reservation of seats is very likely to succeed, and avoid penalizing the likely case with an eager, time-consuming check that will be cheap to perform by the time it is really needed. If the unlikely case happened, then the app shows that to the user.
Added an additional callout

fsimonazzi: should be "events"
Fixed

fsimonazzi: is it elaborated later that this means the web front end needs now to host the domain model and the event store and publishing infrastructure in order to be able to handle commands in-process?
Yes

fsimonazzi: keep in mind that in the context of event sourcing snapshots are sometimes persistent, not transient local caches as implemented in our project.
Added an additional callout

fsimonazzi: This is a bit loose. You can only switch entire deployments, which include all the roles. What we plan to do is to deploy v3 to staging, deactivate the v2 worker role using the maintenance mode flag and activate the v3 worker role so it can handle the messages from the v2 web apps in the production slot from the staging slot. Then the deployments are switched with a VIP swap and the the v3 web apps start serving requests.
Note that the app will still work, and browsing conferences wouldn't be affected.
Tightened up

fsimonazzi: Commented earlier, we save all commands and remove them as they are sent.I can see that's not how the code snippet looks like (it reflects what is described in the text) but I think this is a significant enough difference to require an update to the code snippet. The current code is not just different, it is a different approach.

fsimonazzi: This method is actually async now, but it is still relevant to describe the change, and it does not have the async noise.
Added a comment.

fsimonazzi: The totals calculated exactly represented the seats that were actually reserved for the order, but it took much longer for the unlikely case that not all seats could be reserved. Note that when the information about the seats reserved finally gets to the order, the total will be recalculated if needed, resulting in a new order totals calculated event.
No change

fsimonazzi: Need to be consistent with the terminology. We have inline, synchronous, in memory and in-process.
Tightened this up

fsimonazzi: Note that async loops make the code harder to read and profile, but it's also much more efficient and it is the recommended best practice.
Extended existing callout.

fsimonazzi: I'd spin it differently. We're using sessions to take advantage of certain guarantees that come along with them, but the downside is that while retrieving messages for a session the other messages are not handled. It's only fair to look for additional sessions.
Adjusted

fsimonazzi: The current implementation has changed slightly, but the purpose is still the same.
Updated snippet