3 ms·

This is super important and I cannot stress it enough! If your events contain words like, "create, update, delete, associate, disassociate," then you're buildin

This is super important and I cannot stress it enough! If your events contain words like, "create, update, delete, associate, disassociate," then you're building a weak domain model that won't benefit from the added complexity of deriving state from the source of events. Your events should use the same words your customer would actually use to describe their business process. For example, a system to manage intake of patients in an ER would have events such as Patient Arrived, Patient Screen Completed, Patient Admitted, etc. If you don't have such a vocabulary then you're not capturing interesting events so don't store them. You probably want something that is event driven instead or perhaps simply to log actions to an audit table.

Fire-Dragon-DoL 7y ago
Indeed! It became pretty evident at some point, we had 4 models that had just "created, updated and deleted" and felt weak, suddenly we arrived at one model that had only a "configured" event, that needed all the information from the previous 4. That's when we figured out that the other 4 were pointless, just "UI gimmicks to make the life of the user easier", the only event that was relevant was that "Configured", with all the related information in there. The event modeling is the key part. It also help gaining a much deeper understanding of the business problem the software is trying to solve
btown 7y ago
While this is correct for a LOT of applications, if you ever end up in a situation where multiple automated systems and manual users may be concurrently updating and associating/disassociating records, and last-write-wins won't cut it (due to e.g. some fields being co-dependent) you're going to need to merge their change streams in a custom way. "UpdatedRecordData(Type, ID, Value, Actor, Context, Date)" may not be a domain-specific vocabulary but it's kind of necessary if you're building a system with a data model that can be extended by clients. Event-Sourced Salesforce will be a thing!

Fire-Dragon-DoL 7y ago

Indeed! It became pretty evident at some point, we had 4 models that had just "created, updated and deleted" and felt weak, suddenly we arrived at one model that had only a "configured" event, that needed all the information from the previous 4. That's when we figured out that the other 4 were pointless, just "UI gimmicks to make the life of the user easier", the only event that was relevant was that "Configured", with all the related information in there. The event modeling is the key part. It also help gaining a much deeper understanding of the business problem the software is trying to solve

btown 7y ago

While this is correct for a LOT of applications, if you ever end up in a situation where multiple automated systems and manual users may be concurrently updating and associating/disassociating records, and last-write-wins won't cut it (due to e.g. some fields being co-dependent) you're going to need to merge their change streams in a custom way. "UpdatedRecordData(Type, ID, Value, Actor, Context, Date)" may not be a domain-specific vocabulary but it's kind of necessary if you're building a system with a data model that can be extended by clients. Event-Sourced Salesforce will be a thing!