Où implémenteriez-vous généralement la logique de transaction dans la conception pilotée par domaine?

Question

• Dans le code de la consommation? (comme un contrôleur)
• Dans les référentiels?
• Dans les services?

Answer 1

Pour commencer, c'est une question assez controversée, alors vous aurez forcément beaucoup de réponses différentes. De mon point de vue, les transactions (ACID) sont une caractéristique de certains mécanismes de stockage (notamment les bases de données relationnelles), donc je considère le concept spécifique à la technologie. Avant que quiconque proteste que ce n'est un argument théorique considère qu'il existe plusieurs cas imaginables où le magasin de données (Référentiels) ne serait pas transactionnel:

• Beaucoup entreprise à grande échelle (comme par exemple Amazon) ne pas utiliser transactions pour des raisons de performance. Au lieu de cela, ils ont une architecture qui leur permet de faire face aux défaillances
• services de données REST
• Double test

Puisque les modèles de domaine doivent être découplés de mises en œuvre spécifiques, je trouve logique qu'ils ne savent rien à propos des transactions. Cependant, cela signifie également que les référentiels doivent exposer des opérations de la bonne granularité pour qu'ils puissent, eux-mêmes, gérer les transactions, s'ils le désirent, et qu'une opération soit garantie de succès ou échoue dans son intégralité. En d'autres termes, les référentiels doivent gérer les transactions (le cas échéant).

---

Il y a cependant des situations où cela peut exiger des Référentiels d'avoir trop de connaissances du domaine, de sorte que le modèle de conception Unit of Work fournit une bonne abstraction pour les cas où vous avez vraiment besoin d'une transaction (potentiel) pour couvrir plusieurs opérations sur plusieurs référentiels différents.