Great video, Derek. One thing I'd be interested in hearing more about is how the Marten/Wolverine infrastructure handles event replays without side effects, e.g. rebuild a read model projection (or build a new read model projection) from an event stream without firing associated side effects like emails or app notifications.
Very interesting stuff Derek. Thanks for introducing me to Marten and Wolverine. One thing about Wolverine I'm not a fan of at first sight is that adding custom middleware requires using something called the LamarCompiler. I do like the seemingly clean handler invoking code; although a downside in my opinion would be not having strongly typed results from calling invoke on the IMessageBus. What are your thoughts on this?
You can use Wolverine as a de facto replacement for MediatR, and there is an overload of Invoke to retrieve results. That being said, Wolverine isn't really meant to just be a different MediatR.
Thank you very much for the efforts made. Can hardly see what is on a screen. As it was asking before could you plz publish a complete example with a source code?
Hii ✋ I'm currently working on a project that involves implementing the CQRS pattern and I'm exploring different options for denormalizing data. I've heard that using message queues or distributed jobs using Hangfire are two popular approaches for achieving this. However, I'm still trying to fully understand the benefits and drawbacks of each approach, and I was wondering if you would be willing to create a video discussing the possible scenarios for denormalization when implementing CQRS and comparing the benefits and drawbacks of using message queues versus distributed jobs using Hangfire.
Thank you for the video. As someone who has primarily worked in EF core, this has been very helpful entry point for me to get into Event Sourcing. One question though, even in the same domain boundary it makes sense that you may have multiple related but ultimately separate entities (in case of traditional data persistence approach), are the events of all these entities saved in the same event table? For example I have an email service that i usually inject into my projects, where the admins can constantly update the templates, track the status of individual messages sent, along with subscription status for those messages. Does event sourcing use 3 different "tables" to keep track of the changes to the 3 entities or is it all saved to the same "table" and built up with projections as 3 separate entities?
With event sourcing, your talking in streams rather than tables or collections. How marten does this specifically, I'm not sure how it persists within Postgres, but it's abstracted from you really.
Thank you very much for the efforts made. Please provide a complete example of an application driven-Domain design (DDD). Or a link if possible and stay safe.
Or just use top down cohesive procedure calls updating the database in an atomic transaction. As an insurance company, I wish we had people buying our products at the rate of 500/second. Oh, I guess we could scale up, and our code would still be readable and match the business logic :-) Ahhh, the industry today, shiny objects ... You make the decisions. And make good ones. To the victor*, go the spoils! [*made the right decisions]
1 hour of Event Sourcing and Marten? I can't wait to watch this 👀👀👀
Great video, Derek. One thing I'd be interested in hearing more about is how the Marten/Wolverine infrastructure handles event replays without side effects, e.g. rebuild a read model projection (or build a new read model projection) from an event stream without firing associated side effects like emails or app notifications.
I really wish this library worked with SQL Server. You know, corporate overlords being what they are. :)
Very interesting stuff Derek. Thanks for introducing me to Marten and Wolverine. One thing about Wolverine I'm not a fan of at first sight is that adding custom middleware requires using something called the LamarCompiler. I do like the seemingly clean handler invoking code; although a downside in my opinion would be not having strongly typed results from calling invoke on the IMessageBus. What are your thoughts on this?
You can use Wolverine as a de facto replacement for MediatR, and there is an overload of Invoke to retrieve results. That being said, Wolverine isn't really meant to just be a different MediatR.
Thank you very much for the efforts made. Can hardly see what is on a screen. As it was asking before could you plz publish a complete example with a source code?
github.com/jeremydmiller/EventSourcingWithMarten
Would be interested to hear about the possibility of using Marten at the back of Orleans in an event-sourced system Derek.
I'm glad he used Postgres since the world doesn't revolve around Microsoft and .NET Core is the standard of C# now.
Hii ✋
I'm currently working on a project that involves implementing the CQRS pattern and I'm exploring different options for denormalizing data. I've heard that using message queues or distributed jobs using Hangfire are two popular approaches for achieving this.
However, I'm still trying to fully understand the benefits and drawbacks of each approach, and I was wondering if you would be willing to create a video discussing the possible scenarios for denormalization when implementing CQRS and comparing the benefits and drawbacks of using message queues versus distributed jobs using Hangfire.
Thank you for the video. As someone who has primarily worked in EF core, this has been very helpful entry point for me to get into Event Sourcing.
One question though, even in the same domain boundary it makes sense that you may have multiple related but ultimately separate entities (in case of traditional data persistence approach), are the events of all these entities saved in the same event table?
For example I have an email service that i usually inject into my projects, where the admins can constantly update the templates, track the status of individual messages sent, along with subscription status for those messages. Does event sourcing use 3 different "tables" to keep track of the changes to the 3 entities or is it all saved to the same "table" and built up with projections as 3 separate entities?
With event sourcing, your talking in streams rather than tables or collections. How marten does this specifically, I'm not sure how it persists within Postgres, but it's abstracted from you really.
Thank you very much for the efforts made. Please provide a complete example of an application driven-Domain design (DDD). Or a link if possible and stay safe.
Nothing inherently here is related to DDD. Event Sourcing is a persistence pattern.
Very confusing to be honest.
If you're unfamiliar with Event sourcing, check out ua-cam.com/video/AUj4M-st3ic/v-deo.html
Or just use top down cohesive procedure calls updating the database in an atomic transaction. As an insurance company, I wish we had people buying our products at the rate of 500/second. Oh, I guess we could scale up, and our code would still be readable and match the business logic :-) Ahhh, the industry today, shiny objects ... You make the decisions. And make good ones. To the victor*, go the spoils! [*made the right decisions]
well done @derek comartin