事件溯源是否需查询最新事件版本？DDD应用版本设置存并发疑问

Great questions—let's break them down clearly, since Event Sourcing's version handling is a common point of confusion when starting out.

Short answer: Yes, but not in the way you might think.

In standard Event Sourcing workflows, you do need to know the latest version of your aggregate root—but you shouldn't query for it as a standalone step. Instead, the version is a byproduct of loading the aggregate's full event history to reconstruct its current state.

When you load all events for an aggregate ID, the last event's version (or the aggregate's tracked version) gives you the current "state version." This version is critical for ensuring consistency when writing new events. The mistake to avoid is querying for the version in isolation—because by the time you use that version to write, it might already be outdated (which ties directly to your second question).

Your intuition about concurrency issues here is spot-on—querying the version first, then using it to write events, creates a classic race condition. Two concurrent requests could both fetch the same latest version, then both attempt to write events with the next version number, leading to duplicate events or inconsistent state.

The key point you're missing is that version checking and event writing need to be an atomic operation, handled by your event store (not your application code). Here's how to fix this:

• Use optimistic locking via your event store: Most mature event stores (like EventStoreDB, Axon Server, or even custom SQL-based stores) support conditional writes based on the aggregate's expected version. Here's the correct flow:
  1. Load all events for the aggregate ID to reconstruct its current state, and note the latest version (let's call this currentVersion).
  2. Run your business logic to generate new events—these events should be tagged with currentVersion + 1 (or follow your store's versioning scheme).
  3. Submit the new events to the store, explicitly specifying that you expect the aggregate's current version to still be currentVersion.

The event store will then atomically check if the aggregate's actual latest version matches your expected version. If it does, the events are written and the version is incremented. If not (meaning another process wrote events in the meantime), the store will reject the write with a concurrency exception—at which point you can retry the entire flow (reload the aggregate, re-run logic, re-submit events).

• If building a custom event store: You can enforce this atomicity at the database level. For example, in SQL, you could use an INSERT with a conditional check to ensure no newer version exists for the aggregate:

  INSERT INTO events (aggregate_id, version, event_payload, event_type)
  VALUES (@AggregateId, @NewVersion, @Payload, @EventType)
  WHERE NOT EXISTS (
      SELECT 1 FROM events 
      WHERE aggregate_id = @AggregateId AND version >= @NewVersion
  )
  

  If the insert fails (no rows affected), you know a concurrent write happened and can handle the retry.

The core idea is to shift the responsibility of version consistency from your application code to the event store, which can handle the atomic check-and-write operation safely.

内容的提问来源于stack exchange，提问作者SHM