Search code examples
domain-driven-designcqrsevent-sourcing

Should there be an Update event per Property or an Update event per Entity with Event Sourcing?


I'm currently working on a CMMS software. Most of these packages have some way of managing your inventory, being able to create Purchase Orders to buy more stock, etc.

Part of our system works perfectly with Event Sourcing because there are clearly defined events. But there is also a bunch of attached data that are almost completely unrelated to that whole process and are just used by companies for reporting at a later date.

For example, a Purchase Order might have a department attached to it. We don't use this department in any stage of the Purchase Order, but a company might come along and want a report for 'How much money has each department spent'. On the other hand, another company might be so small/specialized they doesn't even have separate departments so it doesn't care about it.

That's just 1 example, but there can be a decent amount of fields like that (Think 5-10 per Entity). In this kind of situation, is it better to just have a 'PurchaseOrderUpdated' event that covers all these fields? Or is it considered better to have an individual update events like 'PurchaseOrderDepartmentChanged'?

I personally think there should be an event per property, but I think the rest of my team would complain about having to set up that many events.


Solution

  • It sounds like you may be mixing up two different approaches.

    An event in an event sourced system describes a change in state that has already happened. This is typically triggered by a command issued to (typically) an aggregate root. A key feature of these domain objects is that they don't have any public properties. It wouldn't therefore make sense to create an 'Update' per property. Here is a blog post which talks about how events are names and used:

    6 Code Smells with your CQRS Events - and how to avoid them

    Regarding the payload of an event. I have found it better to ensure events are rich in data. A key value of doing event sourcing is the ability to create new read models that you hadn't considered when you initially built the system. Or as you rightly pointed out, create invaluable reporting for the business. IMHO make rich events which include contextual information as well the key information about the state change.