L'article traite de la modélisation des invariants métiers dans le cadre du Domain-Driven Design (DDD) et de l'importance des agrégats (Aggregates). Il aborde la complexité de maintenir ces invariants, notamment lorsque les règles métiers deviennent plus complexes. L'exemple donné est celui d'une application e-commerce où la quantité de produits par commande est limitée. L'article explore deux approches pour gérer ces invariants : une approche simple où l'invariant est vérifié au niveau de l'objet LineItem, et une approche plus complexe nécessitant la dénormalisation des données pour garantir la cohérence éventuelle (Eventual Consistency). Cette dernière méthode implique de dupliquer certaines informations pour éviter des transactions lourdes et potentiellement bloquantes. L'article souligne également l'importance de la discussion avec les experts métiers pour définir les règles de gestion des invariants et introduit le concept de Job Queue pour assurer la mise à jour asynchrone et robuste des données. En conclusion, la complexité de la solution dépend de la volumétrie des données et des exigences métiers.

L'article présente ce que sont les transactions ACID.

Les transactions ACID sont un ensemble de principes garantissant la fiabilité des transactions dans les bases de données. ACID signifie Atomicité, Cohérence, Isolation et Durabilité. Ces propriétés assurent que les transactions sont complètes, maintenant l'intégrité des données même en cas de panne. L'atomicité garantit qu'une transaction est entièrement exécutée ou pas du tout, la cohérence maintient la base de données dans un état valide, l'isolation empêche les interférences entre transactions, et la durabilité assure que les modifications sont permanentes une fois la transaction terminée.

Les transactions ACID sont cruciales dans des domaines comme la finance et le commerce électronique, où l'intégrité des données est primordiale. Cependant, elles peuvent poser des défis en termes de performance et d'évolutivité, surtout dans les systèmes distribués. Les bases de données NoSQL, en revanche, adoptent souvent le modèle BASE (Basically Available, Soft state, Eventual consistency), privilégiant la disponibilité et la flexibilité à la cohérence stricte.

Pour optimiser les transactions ACID, il est recommandé de limiter leur portée, d'utiliser des transactions plus petites, et de choisir des niveaux d'isolation appropriés. La surveillance et l'enregistrement des transactions sont également essentiels pour maintenir les performances du système.

Tout est dans le titre

Tout est dans le titre

En gros, l'auteur nous incite à utiliser les transactions

Le "I" de "ACID" désigne la propriété d'Isolation. PostgreSQL et MySQL / MariaDB ont des comportements très différents, et la migration d'un SGBD à l'autre peut donc présenter quelques surprises / écarts.

Tout est dans le titre

SQL Transaction Isolation Levels Explained