GregYoung 8 CQRS Class
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about CQRS, event sourcing and domain-driven design, as the long-form reference explaining how the command and read sides should be separated.
Recommended by 2 people across 2 different months, 2016 to 2018.
What it is
A recording of Greg Young's roughly six and a half hour online class on DDD, CQRS and Event Sourcing, covering building an event store, evolving an existing architecture, testing, eventual consistency and versioning. It is a long-form course-style session by Greg Young, uploaded to YouTube by Emilio López Arias.
What people said
Recommends tomliversidge · 2016-06 · Stack Overflow · on “Making contexts explicit in the directory structure”
Right now we do not have a nice place to put things that are not part of our domain, yet somehow bind to it. Right now these contexts are not explicitly visible in our code, so it is easy to make them dependent on each other, especially when you are not familiar with the domain. There are both technical and non-technical ways to address this issue: You can enforce stricter separation through class libraries. It is more obvious you are taking a dependency on something if you have to import a dll / reference another project. It will also prevent circular dependencies. Code reviews / discipline is a non-technical way to handle it. I've been using Hexagonal Architecture [LINK] with DDD where the
Recommends tomliversidge · 2016-06 · Stack Overflow · on “Making contexts explicit in the directory structure”
[LINK] is an example of a command handler. In here you could also pass into the constructor the thing that does authorization. An even better approach is to use the decorator pattern on the command handler class itself. See this point in the video i referenced here [this video]
Recommends Constantin Galbenu · 2018-10 · Stack Overflow · on “How to reliably store event to Azure CosmosDB and dispatch to Event Grid exactly once”
You cannot but you shouldn't do it anyway. Maybe there are some very complicated methods using distributed transactions but they are not scalable. You cannot atomically store and publish events because you are writing to two different persistences, with different transactional boundaries. You can have a synchronous CQRS monolith, but only if you are using the same technology for the events persistence and readmodels persistence. In CQRS the application is split in Write/Command and Read/Query sides ( this long video [this video] may help). You are trying to unify the two parts into a single one, a downgrade if you will. Instead you should treat them separately, with different models (see Domain d
Cites guillaume31 · 2018-09 · Stack Overflow · on “Value object in event sourcing”
3/ Yes, some of the DDD "luminaries" don't validate domain rules when applying an event - whether it news up a VO or not. See here [LINK] and there [LINK] and this Greg Young video [this video] .