Problem:

Zwei Mitarbeiter (A & B) werden gleichzeitig offline geschaltet, während sie Kunde Nr. 123 bearbeiten, z. B. Version Nr. 20, und während sie offline weiterhin Änderungen vornehmen ...

Szenarien:

1 - Die beiden Mitarbeiter bearbeiten den Kunden Nr. 123 und nehmen Änderungen an einem oder mehreren identischen Attributen vor.

2 - Die beiden Mitarbeiter bearbeiten den Kunden Nr. 123, nehmen jedoch NICHT dieselben Änderungen vor (sie kreuzen sich, ohne sich zu berühren).

... dann kommen beide wieder online, zuerst wird Mitarbeiter A angehängt, wodurch der Kunde auf Version 21 und dann Mitarbeiter B auf Version 20 umgestellt wird

Fragen:

Welche Änderungen behalten wir in Szenario 1 bei?

Können wir in Szenario 2 eine Zusammenführung durchführen, wie?

Kontext:

1 - CQRS + Event Sourcing-Stilsystem

2 - Verwenden Sie Event Sourcing Db als Warteschlange

3 - Eventuelle Konsistenz des gelesenen Modells

4 - RESTful APIs

EDIT-1: Erläuterungen basierend auf den bisherigen Antworten:

Ich brauche zum Beispiel einen Befehl für jedes der Felder in einem Formular, um eine abgestimmte Zusammenführung durchzuführen.

Übergeordnete, fein abgestufte Befehle für ChangeName, ChangeSupplier, ChangeDescription usw. mit jeweils eigenem Zeitstempel ermöglichen die automatische Zusammenführung in dem Fall, dass A & B beide aktualisierten ChangedName?

Bearbeiten-2: Nachverfolgung basierend auf der Verwendung eines bestimmten Ereignisspeichers:

Es scheint, als würde ich @GetEventStore für die Persistenz meiner Ereignisströme verwenden.

Sie nutzen Optimistic Concurrency wie folgt:

Jedes Ereignis in einem Stream erhöht die Stream-Version um 1

Schreibvorgänge können eine erwartete Version angeben, wobei der ES-ExpectedVersion-Header für Schreibvorgänge verwendet wird

-1 gibt an, dass der Stream noch nicht vorhanden sein sollte

0 und höher gibt eine Stream-Version an

Schreibvorgänge schlagen fehl, wenn der Stream nicht die Version aufweist. Entweder versuchen Sie es mit einer neuen erwarteten Versionsnummer, oder Sie haben das Verhalten erneut verarbeitet und entschieden, dass es in Ordnung ist, wenn Sie dies wünschen.

Wenn keine ES-Expected Version angegeben ist, ist die optimistische Parallelitätssteuerung deaktiviert

In diesem Zusammenhang basiert die optimistische Nebenläufigkeit nicht nur auf der Nachrichten-ID, sondern auch auf der Ereignisnummer.