Patches
Resolving an invoice dispute may require correcting the amount, recording the agreed reason, and marking the dispute resolved. The team knows the outcome it wants. Recording that outcome should be possible while the team is still learning how to describe its business. A patch expresses the intended changes together.
When an event-sourcing system requires predefined events and aggregates, recording a change depends on those modeling decisions. The team must decide which event describes the correction and which aggregate owns the affected information. Those decisions become harder when an operation crosses the boundaries of the original model. Stardust accepts a patch without requiring a fixed aggregate type or an event type for every possible edit.
Intent
The information involved can develop beyond a simple record. A dispute might begin with a reason and later include supporting notes and nested details about the contested items. Objects and collections can describe further detail wherever the information needs it. The intended change can follow that nesting without a predefined aggregate hierarchy. This carries the open ontology through to changes as well as records.
The related changes in one patch succeed together or leave the data unchanged. An invoice should not acquire a corrected amount while losing the explanation that belongs with the correction. Treating them as one change lets the application preserve that agreement. The application still decides which changes belong together for its purpose.
Business meaning
The requested change and its actual effect answer different questions. A caller may include a value that already agrees with the current record. That request expresses intent, but it does not establish that the value changed again. History distinguishes the changes that occurred from the information the caller supplied.
An explanation such as "customer accepted the correction" adds meaning that the changed fields alone cannot establish. Applications can record that context with the change, using the transaction's identity described in Reification. Domain events remain useful when the application needs that vocabulary. They can develop as the team learns, alongside the ability to record changes without a complete event model first.