La déclaration if trouvée dans la plupart des langages de programmation a deux rôles principaux : pour la validation de l'entrée afin de protéger le domaine contre des données erronées et pour traiter la logique métier dans le domaine. Malheureusement, nous consacrons trop peu de temps à gérer les risques liés à l'utilisation de déclarations logiques du point de vue business ou du domaine, a déclaré Udi Dahan dans sa récente présentation lors de la conférence DDD Europe à Amsterdam.
Lors de l’achat d’articles en ligne, nous examinons différents articles et nous lisons des détails sur certains d'entre eux. Lorsque nous trouvons quelque chose à acheter et que nous l'ajoutons par la suite au panier d'achat, nous passons également de l’aspect requête à l’aspect commande de l'interaction. Une des questions importantes que Dahan pense que nous devrions demander à n'importe quel type de commande, est qu'est-ce qui causerait son échec, et souligne que nous devons distinguer les échecs techniques, comme un crash du serveur web ou une certaine erreur de désérialisation, qui devrait être géré par l'infrastructure, des défaillances logiques, comme l'ajout d'un élément au panier juste après que le même article ait été supprimé du catalogue de produits.
Vérifier si quelque chose est supprimé est un exemple qui revient souvent dans le travail de Dahan avec ses clients. Pour lui, une étape dans le traitement des problèmes comme les éléments supprimés est de faire une distinction entre les données privées et publiques et qui se compare à un système de gestion de contenu où vous éditez les pages et le contenu et finalement rendez les informations publiques en appuyant sur un bouton Publier. Côté privé, un utilisateur peut ajouter un élément, le mettre à jour ou le supprimer sans problème, et enfin quand il est satisfait, le rendre public.
Côté public, nous devons remplacer les suppressions et les vérifications de suppression par une logique plus centrée sur le business ; nous devons penser davantage à la raison pour laquelle un élément doit être supprimé. Un exemple est un produit qui n'est plus à vendre ; alors peut-être une meilleure manière est de créer une commande spécifique qui marquera le produit comme non à la vente, au lieu d'utiliser une certaine forme de suppression soft ou réelle.
Un problème potentiel avec une telle solution est la condition de concurrence où un client ajoute un article au panier juste avant que le même article soit marqué comme non à la vente. Plus tard, lorsque le client veut vérifier le panier, il n'est plus possible d'acheter cet article. L'examen du problème de cette manière est, pour Dahan, une perspective très ponctuelle centrée sur les données ; au lieu de cela, il décrit le problème comme un scénario typique avec plusieurs acteurs travaillant sur le même objet en même temps.
Dans un domaine collaboratif, avec plusieurs acteurs opérant sur les mêmes données en parallèle, Dahan pense que nous devrions commencer à penser au CQRS. Avec l’application de CQRS à un domaine, sa recommandation est de le rendre aussi simple que possible et de concevoir la solution afin qu'une commande qui a été validée et qui entre dans la logique de domaine n’échoue presque jamais. Cela signifie que lors de la manipulation d'une commande, nous devons par exemple être prêts à échouer dans une condition de concurrence et toujours remplir les objectifs globaux du business. Souvent, cela conduit à une cohérence éventuelle, mais pas au type technique avec un modèle de lecture qui finit par devenir en synchronisation avec un modèle d'écriture ; mais plutôt d'un point de vue business. Dans cet exemple, il s'agit de clients ajoutant un élément à leur panier qui n'est pas à vendre.
Une solution à cela est d'utiliser un process de longue durée qui derrière la scène supprime l'élément qui n’est pas à vendre des paniers de shopping comme ils deviennent inactifs ou suite à un time out. Finalement, l'article a été retiré de tous les paniers et donc pas vendu.
Lorsque nous examinons un système, nous trouvons probablement beaucoup d'autres déclarations if qui vérifient l'état sous une forme quelconque et pour chacune d'elles nous devrions nous demander s'il existe d'autres acteurs qui peuvent changer le même état. De cette manière, nous pouvons trouver des collaborations et des besoins potentiels pour un process de longue durée. Cependant, Dahan note que nous devons être conscients de l'utilisation abusive des longs process, et souligne que ce n'est pas le remède miracle.