La création d'applications nécessitant une mise à l'échelle indépendante des lectures et des écritures est difficile avec les modèles CRUD traditionnels. Cette compétence fournit des modèles et motifs CQRS prêts à l'emploi pour séparer les responsabilités de commande et de requête, permettant des performances optimisées pour les charges de travail intensives en écriture et lourdes en lecture.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "cqrs-implementation". Comment séparer les opérations de lecture et d'écriture dans mon application Python?
Résultat attendu:
- CQRS sépare votre application en deux modèles distincts : les Commandes (opérations d'écriture qui modifient l'état) et les Requêtes (opérations de lecture qui retournent des données). La compétence fournit des modèles Python montrant comment implémenter des gestionnaires de Commande et de Requête, un bus de commande pour le dispatching et des modèles de lecture séparés optimisés pour des motifs de requête spécifiques.
- Les composants clés incluent : classe de base Commande avec validation, interface CommandHandler, CommandBus pour le routage, classe de base Requête, QueryHandler pour la récupération de données et ReadModelSynchronizer pour garder les vues à jour.
Utilisation de "cqrs-implementation". Montrez-moi comment gérer le délai entre l'écriture des données et leur lecture
Résultat attendu:
- Cela s'appelle la cohérence finale. La compétence inclut un motif ConsistentQueryHandler qui peut attendre que le modèle de lecture rattrape après une écriture. Il interroge la version de la projection et réessaie jusqu'à atteindre la version attendue, avec un timeout configurable.
- Si le timeout expire, il retourne les données obsolètes avec un flag d'avertissement afin que votre application puisse décider s'il faut procéder ou notifier l'utilisateur.
Audit de sécurité
SûrStatic analysis detected 30 potential issues, but all are false positives. The scanner misidentified markdown code fences as shell execution, database queries as network fetches, documentation URLs as suspicious, and sort order strings as weak cryptography. This is a legitimate CQRS educational skill with Python code templates. No actual security risks identified.
Score de qualité
Ce que vous pouvez construire
Construire une plateforme e-commerce haute performance
Séparer le traitement des commandes (écritures) de la navigation dans le catalogue produits (lectures) pour gérer les pics de trafic du Black Friday avec différentes stratégies de mise à l'échelle.
Implémenter un tableau de bord d'analytique en temps réel
Créer des modèles de lecture optimisés pour les requêtes d'agrégation complexes tout en gardant les opérations d'écriture simples pour les pipelines d'ingestion de données.
Migrer une application monolithique vers une architecture basée sur les événements
Introduire CQRS de manière incrémentale pour séparer les préoccupations et se préparer aux futures capacités d'événement sourcing.
Essayez ces prompts
Aidez-moi à configurer une structure CQRS de base en Python. J'ai besoin de classes de base pour les commandes et les requêtes, d'un bus de commande et de gestionnaires simples pour un domaine de gestion des utilisateurs.
Montrez-moi comment implémenter une projection de modèle de lecture qui garde un profil utilisateur dénormalisé synchronisé avec les événements du domaine. Incluez la gestion des points de contrôle pour la résilience.
Créez une application FastAPI avec des points de terminaison POST/DELETE séparés pour les commandes et des points de terminaison GET pour les requêtes, en utilisant l'injection de dépendances pour les buses de commande et de requête.
Implémentez un gestionnaire de requêtes qui peut attendre la synchronisation du modèle de lecture après une opération d'écriture, avec un timeout et un avertissement de données obsolètes pour la cohérence lecture-après-écriture.
Bonnes pratiques
- Commencez par une frontière claire entre les commandes et les requêtes - ne mélangeons pas la logique de lecture et d'écriture dans le même gestionnaire
- Concevez les modèles de lecture spécifiquement pour leurs motifs de requête plutôt que d'essayer de créer une vue универсальная
- Implémentez des gestionnaires de commandes idempotents pour permettre des réessais sécurisés lors des pannes réseau
Éviter
- Interroger la base de données d'écriture à l'intérieur des gestionnaires de commandes - les commandes doivent seulement valider et persister, ne jamais lire pour la logique métier
- Créer un modèle de lecture unique qui essaie de servir tous les motifs de requête - cela defeats l'objectif des modèles de lecture optimisés
- Ignorer la cohérence finale et supposer une disponibilité immédiate de lecture après écriture sans gestion appropriée