jonsequitur
commented
7 years ago This is a nontrivial problem and I've seen it proposed before. While you could potentially make an event like this, it would only work as long as you maintain the convention-based parity between your aggregate's properties and the event's properties.
Additionally, chances are that your projection code won't know how to interpret the event, so your system will be in an inconsistent state. At the time you make this change, you'll also be putting your system into an untested state.
People often use the ability to tweak the data in a single-model system to "fix" customers. It's a double-edged sword. Those customers' data ends up in a state that the system doesn't normally produce, and they often end up broken in other ways.
200 would be a prerequisite
"A feature" of old style database centric architecture is people can override any field by just log into the database and change it without deployment. This is not necessary a bad thing, and that happen a lot in reality.
Imagine there is an angry customer call "If you do not lower the price of my DVD subscription to $7/month I will switch to Netflix and twitter to everybody", and this customer has 1M followers. If there is no existing event happened to consider this case, we need to add new event an deploy it and run it. While database centric system can just log in and do an UPDATE subs SET money = 7 WHERE NAME = ''angry'.
Event Sourcing system should have a "feature parity".
Since events should be append only, there should be a kind of "hammer" event that can override anything. It would be something like
Event name -- Override { "MonthlyPrice": 7, "Reason": "Angry customer called at today and Scott said we should just lower the price", "Operation": "Will" }