arch-event-sourcing

One-line summary

Persist the sequence of state-changing events as the source of truth. Current state is derived by replaying events. The event log is append-only, immutable, and authoritative.

When to use this skill

• Audit / regulatory requirements that demand a complete history of changes.
• Business that genuinely thinks in terms of "what happened" (banking transactions, claim adjustments, supply-chain events).
• Need to answer temporal queries ("what was the state on date X").
• Multiple projections of the same data needed and easier to materialize from events than to maintain by hand.
• Pairs naturally with CQRS (see arch-cqrs) when reads need different shapes than the canonical event stream.

When NOT to use this skill

• The domain doesn't think in events — forcing the model into event shape is more cost than benefit.
• Current state is sufficient and history is rarely queried — CRUD is simpler.
• Team unfamiliar with eventual consistency, replay semantics, or event versioning — operational pain is severe.
• "Event sourcing" because microservices are trendy and we read about it somewhere — that's not a reason.