3 ms·

I'm working with an event sourced system and we did some mistakes in the process of the design, so some areas that didn't need event sourcing do have it. The b

I'm working with an event sourced system and we did some mistakes in the process of the design, so some areas that didn't need event sourcing do have it. The biggest downside has been the UI: events are not real time and these objects are just CRUD stuff, so the user wants to see that you saved what he has just written. You might not have this information yet, so you need to mitigate it, for example updating the UI through sockets (lot of additional work). On the upside, we are acquiring a lot more insights in what business processes bring value and are meaningful, versus what I call "just configuration". We figured out quite a few rules of thumb over time that are helpful though. One thing I noticed over time is that on average there is no need for "created" and "updated" event, usually there is one meaningful business event that would encompass both (not always the case), e. g. "product listed", or something along those lines. This not only saves lines, but some code reacting to this event has a reduced interaction surface (less bugs and coupling), as well as being more expressive. If you might be interested, we chat a lot about event sourcing in the Eventide Slack channel: https://eventide-project.org/#community-section https://eventide-project.org/#community-section

agentultra 7y ago
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!

agentultra 7y ago

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!