If I have an entity that is very data heavy, with a lot of different properties. And there might be more added in the near future. And it's going to be handled in a crud manner. Would it work with just making a lot of events for adding, updating and removing different properties? It seems like it is going to be way to many events, but it still seems like the best way to manage a lot of different properties, and allow for new properties to be added, without needing to change old events. Any thoughts? 😅
I've been struggling with these events a while ago. I finally published the events depending on what I need in the same boundary, but when it comes to outside the boudary, I just publish a CRUD event with the sku. Good explanation! My next struggle is concurrency, when 2 users are working on the same Order for example. How would I know what the other user have changed. I end up doing a refresh manually...
Meaning you want the UI to be a bit more adaptive to the changes happening concurrently? You could leverage websockets if you're in a webapp. Check this video if you haven't already: th-cam.com/video/Tu1GEIhkIqU/w-d-xo.html
Hmm where is the CRUD event published too? As if you’re building projections with them how do you expect to make that work when you reset and having out of order events?
@@BradleyWeston92 This isn't about event sourcing but for communication between boundaries for either data propagation or notification for business process.
Thank you very much for this great video. I've been following your videos and it would be great to know your thought on Queue Fairness when dealing with messages in a multi-tenant application, suppose you have a subscriber worker that processes unit-of-work from these tenants and you like to make the processing fair enough that no matter how many messages from one tenant is being published to a queue, the other tenants do not get impacted by their work being processed with delay. One idea to have one queue per tenant but if you have a high number of tenants then it might be redundant to have all these queues, or we can have a pool of queues and use them on demand...
Well you could do queue/topics per tenant but really you'd want (competing) consumers per tenant against that queue/topic per tenant. The consumers are ultimately how you would level/separate the compute for messages for specific tenants. Good question btw, gives me another topic idea.
Thank you for the video. Can you explain, pls: why do you define events as inner records inside some empty class and not just using the specific namespace for them?
Hey Derek, quick question, do you any reason to avoid exposing both event types outside the boundary? Say I have consumers that need crud based to build a cache as well as other consumers that want to react to a business event. You could just ignore event types you don’t care about if on the same topic, or perhaps there is a better pattern you’d recommend?
You can publish both. I'm hesitant with Entity/property change events based on CRUD. Event carried state transfer can have it's place but be careful that it's obvious to consumers that they probably don't want to handle both.
How would you support both a task-based UI, along with responding to events from an external bounded-context that are more CRUDy? For example, say your system ingests an OrderUpdated CRUD event with the whole entity, and you need to internally figure out which command to dispatch based on the entity data (CreateShipment, CancelShipment, etc.)
@@CodeOpinion Thanks 😭. Yeah basically we need to integrate with an external BC that's on a completely different team and we only get generic 'entity updated' events with the whole entity payload. Puts all the burden on the consumer to figure out what changed
in the video there are three types of events being introduced, while they are all well expalined, it skips the question of weather Events or Commands should be published. specifically, should we publish ProductShipped event when we receive task from user, or should we givev out ShipProduct commands?
I think you're asking if you should use orchestration or choreography, but I do think this is a good question and topic idea. Check out: th-cam.com/video/rO9BXsl4AMQ/w-d-xo.html regardless.
@@CodeOpinion wow, its amazing how quick you replied my question, really appreciate that. and yes, i have watched the video for a quite a few times. in the video you mention that a centric orchestrator knows how to respond to each event and gives out corresponding command so that other services just "do what they are told", while in choreography approch every service needs to know how to respond to certain events, so domain knowledge is kind of "distributed" to services.
@@CodeOpinion but for the entry of the program, like a restful api for create user, would it be just orchestration approach availble? since there won't be previous events sent to the create_user api
Can you combine a CRUD Property with Behavioral Events? For example, say I have a ProductShipped event that has a 'Reason' Enum type parameter from which I can derive the reason this event occurred. Like 'Reason.INVENTORY_ADJUSTED'? I imagine this is possible but slightly messy in certain situations. Thank you for the helpful videos on Event Driven Architecture. It's taught me a lot!
Yes, you could go down that road for sure. Depending on the broker and messaging library you're using however, you may only want to handle a specific "event type". A lot of this really revolves around the library you're using. I'll talk more about this in a future video about why messaging libraries are something you should use and not abstract.
Would you chain events by declaring high level (behavioural) events, which trigger lower level property change events, which themselves trigger simple entity events?
The issue there is if you do that, and then a service consumes both behavior event and the data change event for the same reason, it would need to be idempotent.
Hi Derek. Are there cases where CRUD by property is appropriate? I’m thinking of a situation where the UI allows the user to update as you go, that is, each time a field is changed, the database would be updated. It “feels” like it should be an event but does fit the CRUD by Property anti-pattern.
Some stuff is just generally CRUD and doesn't need to be task based. In these cases, you will end up with CRUD by entity or property. It's not inherently bad unless you should be capturing intent and because you're not you end up trying to infer it.
Your channel is a gem in TH-cam jungle! Great content!
I can't believe these are free knowledge. I'm really thankful. I will definitely become a Patreon in the future.
I should name it "domain event focused" than behavioral but is amazing video
If I have an entity that is very data heavy, with a lot of different properties. And there might be more added in the near future. And it's going to be handled in a crud manner.
Would it work with just making a lot of events for adding, updating and removing different properties? It seems like it is going to be way to many events, but it still seems like the best way to manage a lot of different properties, and allow for new properties to be added, without needing to change old events.
Any thoughts? 😅
I've been struggling with these events a while ago.
I finally published the events depending on what I need in the same boundary, but when it comes to outside the boudary, I just publish a CRUD event with the sku.
Good explanation!
My next struggle is concurrency, when 2 users are working on the same Order for example. How would I know what the other user have changed. I end up doing a refresh manually...
Meaning you want the UI to be a bit more adaptive to the changes happening concurrently? You could leverage websockets if you're in a webapp. Check this video if you haven't already: th-cam.com/video/Tu1GEIhkIqU/w-d-xo.html
I currently only know WPF desktop. But I'm thinking about WCF also. Thanks for the reply.
Hmm where is the CRUD event published too? As if you’re building projections with them how do you expect to make that work when you reset and having out of order events?
@@BradleyWeston92 This isn't about event sourcing but for communication between boundaries for either data propagation or notification for business process.
Thank you very much for this great video. I've been following your videos and it would be great to know your thought on Queue Fairness when dealing with messages in a multi-tenant application, suppose you have a subscriber worker that processes unit-of-work from these tenants and you like to make the processing fair enough that no matter how many messages from one tenant is being published to a queue, the other tenants do not get impacted by their work being processed with delay.
One idea to have one queue per tenant but if you have a high number of tenants then it might be redundant to have all these queues, or we can have a pool of queues and use them on demand...
Well you could do queue/topics per tenant but really you'd want (competing) consumers per tenant against that queue/topic per tenant. The consumers are ultimately how you would level/separate the compute for messages for specific tenants. Good question btw, gives me another topic idea.
Thank you for the video. Can you explain, pls: why do you define events as inner records inside some empty class and not just using the specific namespace for them?
No reason at all and it wasn't intentional.
Hey Derek, quick question, do you any reason to avoid exposing both event types outside the boundary? Say I have consumers that need crud based to build a cache as well as other consumers that want to react to a business event. You could just ignore event types you don’t care about if on the same topic, or perhaps there is a better pattern you’d recommend?
You can publish both. I'm hesitant with Entity/property change events based on CRUD. Event carried state transfer can have it's place but be careful that it's obvious to consumers that they probably don't want to handle both.
Too good man .
Can you suggest a design pattern which i can integrate entire crud via a frontend
I'd assume most languages/platforms have some type of library or framework to scaffold basic CRUD for an entity.
How would you support both a task-based UI, along with responding to events from an external bounded-context that are more CRUDy? For example, say your system ingests an OrderUpdated CRUD event with the whole entity, and you need to internally figure out which command to dispatch based on the entity data (CreateShipment, CancelShipment, etc.)
Good luck! You'd basically be trying to infer it. But that's exactly the problem, publish events relative to the use case of the consumers.
@@CodeOpinion Thanks 😭. Yeah basically we need to integrate with an external BC that's on a completely different team and we only get generic 'entity updated' events with the whole entity payload. Puts all the burden on the consumer to figure out what changed
As I understand SKU is some kind of Identity?
Yes a SKU is just a unique product number.
Correct.
Again great video. I'm wondering about how to design HTTP API endpoints for behavioral approach. Can you provide example for the quantity?
Check out this video on creating Task Based UIs if you haven't already. th-cam.com/video/DjZepWrAKzM/w-d-xo.html
in the video there are three types of events being introduced, while they are all well expalined, it skips the question of weather Events or Commands should be published. specifically, should we publish ProductShipped event when we receive task from user, or should we givev out ShipProduct commands?
I think you're asking if you should use orchestration or choreography, but I do think this is a good question and topic idea. Check out: th-cam.com/video/rO9BXsl4AMQ/w-d-xo.html regardless.
@@CodeOpinion wow, its amazing how quick you replied my question, really appreciate that. and yes, i have watched the video for a quite a few times. in the video you mention that a centric orchestrator knows how to respond to each event and gives out corresponding command so that other services just "do what they are told", while in choreography approch every service needs to know how to respond to certain events, so domain knowledge is kind of "distributed" to services.
@@CodeOpinion but for the entry of the program, like a restful api for create user, would it be just orchestration approach availble? since there won't be previous events sent to the create_user api
Yes, generally a command.
Can you combine a CRUD Property with Behavioral Events? For example, say I have a ProductShipped event that has a 'Reason' Enum type parameter from which I can derive the reason this event occurred. Like 'Reason.INVENTORY_ADJUSTED'? I imagine this is possible but slightly messy in certain situations.
Thank you for the helpful videos on Event Driven Architecture. It's taught me a lot!
Yes, you could go down that road for sure. Depending on the broker and messaging library you're using however, you may only want to handle a specific "event type". A lot of this really revolves around the library you're using. I'll talk more about this in a future video about why messaging libraries are something you should use and not abstract.
Would you chain events by declaring high level (behavioural) events, which trigger lower level property change events, which themselves trigger simple entity events?
or is that overkill?
The issue there is if you do that, and then a service consumes both behavior event and the data change event for the same reason, it would need to be idempotent.
Great content. Thanks!
Glad you liked it!
Hi Derek. Are there cases where CRUD by property is appropriate? I’m thinking of a situation where the UI allows the user to update as you go, that is, each time a field is changed, the database would be updated. It “feels” like it should be an event but does fit the CRUD by Property anti-pattern.
Some stuff is just generally CRUD and doesn't need to be task based. In these cases, you will end up with CRUD by entity or property. It's not inherently bad unless you should be capturing intent and because you're not you end up trying to infer it.
what's wrong with CC?
Auto generated by YT.
Thanks Derek. Algorithm, do your thing.
I appreciate that!
Amount of video likes was updated.
Thanks!