Doctrine

Une dépendance ne répond plus : servir une copie, attendre ou refuser dépend de l’opération. Les réponses HTTP doivent rendre ce choix clair pour le client.

GET sert souvent les vues de lecture, tandis que les écritures demandent une décision métier. REST et CQRS se combinent sans imposer le même découpage.

Une réponse perdue ne signifie pas que l’opération a échoué. Méthodes HTTP, clés d’idempotence et suivi du résultat aident à réessayer sans créer de doublon.

Un agent doit pouvoir identifier le contrat utilisé et comprendre son évolution. Versions, dépréciation, liens et erreurs explicites facilitent la migration.

Un agent peut écrire à partir d’une ancienne version. Une précondition vérifiée par le serveur permet de détecter le conflit et de reprendre sur un état relu.

Instructions, outils, documents et historique composent le contexte d’un agent. Comment les choisir, les organiser et vérifier leur utilité pour la tâche ?

Les sites distinguent de plus en plus les robots de recherche, d’entraînement et les agents personnels. Voici les règles d’accès et leurs effets sur la lecture.

Une instruction plus précise peut éviter des recherches et des essais inutiles. Pour réduire le coût d’un agent, comparez les sessions complètes et le cache.

Un grand catalogue occupe du contexte et peut compliquer le choix des outils. La découverte à la demande aide, à condition de mesurer la réussite de la tâche.

Rendre le code modulaire ne demande pas forcément de créer des services. Une interface claire et des dépendances maîtrisées peuvent déjà isoler les changements.

Un service indépendant apporte de l’autonomie, mais ajoute du réseau et de l’exploitation. Voici les besoins à mesurer avant de séparer un module du monolithe.

Un module perd son autonomie quand ses règles et ses données se dispersent. Voici les signes à examiner et les moyens de garder des frontières compréhensibles.

Dans un monolithe, un traitement différé peut laisser deux modules en décalage. Quand faut-il attendre une réponse et comment gérer une mise à jour tardive ?

Une application peut se déployer en un bloc et garder des modules distincts. Exemple avec l’inscription et la facturation, leurs données et leurs échanges.

CQRS sépare les modèles de commande et de lecture. L’event sourcing conserve les événements comme référence : deux choix, avec leurs avantages et coûts.

Réserver un vol puis un hôtel peut échouer à mi-parcours. Une saga organise les étapes, leur reprise et les compensations pour terminer le traitement.

Une commande validée peut manquer quelques instants dans une liste, même dans un monolithe. Voici d’où vient ce délai et comment le rendre compréhensible.

Une liste de commandes, une recherche et un tableau de bord ont des besoins différents. Le read model prépare ces vues et permet de gérer leur mise à jour.

Deux clients achètent le dernier billet : comment éviter la double vente et envoyer la confirmation ? Transaction, concurrence et outbox expliquées pas à pas.

Avec CQRS, réserver une chambre et afficher les disponibilités reposent sur deux modèles adaptés à ces besoins. Deux bases de données ne sont pas obligatoires.

Un agent peut suivre les liens et les actions d’une API hypermédia. Voici comment cela fonctionne, ce que MCP apporte et les critères utiles pour choisir.

Avec htmx, le serveur renvoie des fragments HTML prêts à afficher. Cette approche simplifie certains écrans, avec des limites pour les usages très riches.

Une API peut utiliser les ressources et les méthodes HTTP sans proposer d’hypermédia. Ce choix influe sur la découverte des actions et l’évolution des clients.

Une réponse hypermédia contient des données, des liens et des actions. Le client suit ces indications, tout en partageant un vocabulaire clair avec le serveur.