Compétences event-sourcing-architect
📦

event-sourcing-architect

Sûr

Design Event-Sourced Systems

Build audit-ready systems with complete change history. This skill helps architects implement event sourcing, CQRS, and event-driven patterns for systems requiring temporal queries and reliable audit trails.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez Ă  utiliser

Tester

Utilisation de "event-sourcing-architect". Design an event store for an order management system

Résultat attendu:

  • Event Store Schema: events table with aggregate_id, event_type, payload (JSON), metadata, timestamp, version
  • Aggregate Table: tracks current state, last event version for optimistic locking
  • Event Types: OrderCreated, ItemAdded, PaymentProcessed, OrderShipped, OrderCancelled
  • Indexes: By aggregate_id for replay, By timestamp for audit queries, By correlation_id for saga tracing

Utilisation de "event-sourcing-architect". How do I handle eventual consistency in my read models?

Résultat attendu:

  • Use asynchronous projection updates - commands commit to event store, projections update separately
  • Implement 'read-your-writes' consistency at UI level by querying own writes first
  • Add correlation IDs to link commands to their resulting read model updates
  • Consider read model prefixes or versioning to indicate freshness to users
  • Provide feedback mechanisms when data may be stale (e.g., 'updating...' indicators)

Audit de sécurité

Sûr
v1 • 2/24/2026

Static analysis flagged 8 instances of 'weak cryptographic algorithm' pattern in SKILL.md. Upon evaluation, all findings are FALSE POSITIVES - the scanner incorrectly matched software architecture terms like 'event sourcing', 'event store', 'event versioning', and 'command handlers' as potential cryptographic issues. This is a documentation-only skill with no executable code. No security concerns identified.

1
Fichiers analysés
61
Lignes analysées
1
résultats
1
Total des audits

Problèmes à risque élevé (1)

False Positive: Weak cryptographic algorithm detection
Static scanner flagged lines containing words like 'event', 'store', 'version' as potential weak cryptographic algorithms. These are legitimate software architecture terms (event sourcing, event store, event versioning) and have no cryptographic functionality.
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
95
Sécurité
100
Conformité aux spécifications

Ce que vous pouvez construire

Financial Transaction Systems

Build systems requiring complete audit trails for compliance. Perfect for banking, accounting, or regulatory reporting where every state change must be traceable.

E-commerce Order Management

Implement complex order workflows with saga patterns. Handle multi-step processes like payment, inventory reservation, and shipping with compensating transactions.

Temporal Analytics Platforms

Enable 'what-if' analysis and historical state reconstruction. Allow business users to query system state at any point in time for reporting and debugging.

Essayez ces prompts

Basic Event Store Design
Design an event store schema for [DOMAIN]. What tables or collections do I need? How should I structure events?
CQRS Implementation
Show me how to implement CQRS for a [ENTITY] aggregate. Include command side and query side separation.
Saga Orchestration
Design a saga pattern for [BUSINESS_PROCESS] that involves [STEPS]. How do I handle compensation if a step fails?
Projection Strategy
Create a projection strategy for [QUERY_REQUIREMENT]. What read models should I build and how do I keep them in sync?

Bonnes pratiques

  • Design events as immutable facts about what happened, not as state changes or commands
  • Start event versioning from day one - even if schema seems stable, future changes will need it
  • Use correlation IDs and causation IDs to trace events across aggregates and sagas

Éviter

  • Deleting or mutating committed events - this destroys audit integrity and breaks projections
  • Using events directly in queries instead of building optimized read projections
  • Implementing strong consistency requirements in event-sourced systems - embrace eventual consistency

Foire aux questions

When should I choose event sourcing over traditional CRUD?
Choose event sourcing when you need complete audit trails, temporal queries, or complex business workflows with compensating actions. Avoid it for simple domains where CRUD is sufficient and eventual consistency is not acceptable.
How do I handle schema changes in event-sourced systems?
Use event versioning. Add new fields with defaults, never remove fields. Create upcasters or migration logic to transform old event formats when reading. Plan for multiple event versions to coexist.
What is the relationship between event sourcing and CQRS?
CQRS (Command Query Responsibility Segregation) often complements event sourcing but they are separate patterns. Event sourcing stores state as a sequence of events. CQRS separates read and write models. They work well together but are not dependent on each other.
How do I rebuild projections without affecting production?
Build projections in a separate staging environment first. Test with realistic data volumes. Use snapshotting to speed up rebuilds. Consider blue-green deployment for projection updates.
Can event sourcing work with microservices?
Yes, event sourcing is excellent for microservices. Each service owns its event streams. Use sagas for cross-service workflows. Share event definitions via contracts, not shared databases.
How do I handle duplicate events in event sourcing?
Make event handlers idempotent. Design events to contain all data needed to apply them without external state. Use event store features for deduplication if available. Track processed event IDs to prevent duplicate processing.

Détails du développeur

Structure de fichiers

đź“„ SKILL.md