RightExpressionHelper

[nfaugout-lucca]

Dans le même esprit que l'instanciator, je me pose des question sur le bienfondé de la nouvelle organisation des responsabilités concernant la gestion des droits. Maintenant que la dépendance est au niveau des Repos, on a :

• la Collection qui ne sait pas que les droits sont filtré à un moment donné, donc on pourrait penser que les droits sont géré au niveau de l'Infra
• dans le Repo on a en effet une méthode ApplyRights( )
• qui s'appuie sur un IRightExpressionHelper, qui trouve son instanciation dans le Domain.

Donc au final, les droits sont de la responsabilité du Domain (c'est plutôt bien), mais injectés depuis les Repos qui sont dans l'Infra (ça c'est bizarre), et surtout via une interface, donc IL FAUT que les règles d'injection soit "bonnes", càd qu'on injecte le "bon" RightHelper dans le "bon" Repos pour que ça fonctionne.

Je n'ai pas de solution miracle, car certains de ces pb étaient déjà présents avant la modif, mais je trouve que ça s'est complexifié.

Etant donné que les Repos délègues la gestion des droits au RightHelper, et que celui-ci est codé dans le Domain, voici ce que je ferai :

• injecter un IRightExpressionHelper DANS les méthodes GetAsync( ) & CountAsync, càd partout où le Repo en a besoin
• ainsi la Collection pourrait envoyer le IRightExpressionHelper au Repo (et donc on inverse la responsabilité, c'est la collection qui maitrise son rightHelper, vu qu'il est rattaché au Domain)
• reste que la Collection n'instancie pas elle-même le RightHelper vu qu'il serait référencé sous forme d'interface dans son constr. C'est le dernier pb. Pour moi un Helper ne devrait pas implémenter d'interface, car c'est une classe d'aide qui a comme vocation de déporter du code d'une classe déjà trop chargée. Il n'a pas vocation à être utilisé par une autre classe. Donc au final la solution serait que la Collection instancie elle-même le RightHelper (et donc récupère ses dépendances, à savoir IPrincipal et ICombinationsHolder). L'alternative, c'est que la collection signe un IMyEntityRightExpressionHelper, et qu'il n'y ait qu'une seule classe qui implémente cette interface. Ca revient à éviter de s'emêler les pinceaux au moment de la config de l'injection, car ce sera trivial (Register<IMyEntityRightExpressionHelper, MyEntityRightExpressionHelper>), et ça permet de ne pas remettre les 2 dépendances du RightHelper au niveau de la Collection ! ouf !

[Poltuu]

---

Déjà en fond, j'aimerai souligner que nos couches actuelles, avec WebController/AppController/Collection/Repository/StorageService est assez éloigné de ce qui se fait "classiquement" dans le DDD (https://docs.microsoft.com/fr-fr/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice) et manque de simplicité.

Je sais qu'on ne fait pas du DDD dans toutes les règles de l'art, mais le concept de Collection n'existe quand même nul part ailleurs, et la nuance AppController/Collection/repository n'est pas simple à absorber/comprendre/justifier. Je l'ai vu avec l'équipe poplee. Dans ce contexte, savoir ou mettre les droits n'est déjà pas simple, et je pense que c'est le fond du problème.

L'implémentation actuelle a compris le repository comme un traducteur de l'objet Query vers une expression SQL-compatible. Egalement, il a été introduit avec cleemy-achat, pour introduire les objets DTO en sortie de la base de données et permettre au repository de ressortir des objets mappés, besoin dont on ne parle plus.

Afin de se rapprocher un peu de ce qu'on peut voir dans la littérature et simplifier la gestion des droits, j'aimerai nous rapprocher d'une archi de ce type https://github.com/dotnet-architecture/eShopOnWeb/tree/master/src (repo de l'exemple m$)

• webcontroller gère la sérialization/déserialization/routing/ création de l'objet Query (qui d'ailleurs pourrait être renommé en QuerySpecification, puisque c'est le pattern que l'on utilise sans le savoir) - rien ne change
• appcontroller orchestre https://github.com/dotnet-architecture/eShopOnWeb/tree/master/srcen cas de besoin - rien ne change
• collection est supprimé : on ne passe pas par le domain dans un appel d'api classique
• repository s'étoffe en reprenant qq morceaux de collection. Il expose des méthodes dédiées pour les services du domain qui le nécessitent. Il gère bien entendu les droits.

  ---

Concernant ta proposition

injectés depuis les Repos qui sont dans l'Infra (ça c'est bizarre), et surtout via une interface, donc IL FAUT que les règles d'injection soit "bonnes", càd qu'on injecte le "bon" RightHelper dans le "bon" Repos pour que ça fonctionne.

On dirait que tu remets en cause le principe d'injection de dépendance, qui en effet, en présence d'un enregistrement défaillant défaille :). Il y a une différence entre la responsabilité de devoir faire les choses, et celle de savoir comment les faire, et c'est ce la DI permet et qu'on retrouve ici. Les repos sont responsables d'appeler le système de gestion des droits, mais ce n'est pas de leur ressort de savoir comment appliquer les droits

ainsi la Collection pourrait envoyer le IRightExpressionHelper au Repo (et donc on inverse la responsabilité, c'est la collection qui maitrise son rightHelper, vu qu'il est rattaché au Domain)

Je ne vois pas bien ce que cela change face à tes objections: les collections se feront toujours injectés ce composant, donc elles n'auront pas plus de pouvoir sur son comportement

Pour moi un Helper ne devrait pas implémenter d'interface, car c'est une classe d'aide qui a comme vocation de déporter du code d'une classe déjà trop chargée. Il n'a pas vocation à être utilisé par une autre classe.

Pour moi, c'est une pirouette syntaxique ce truc, parce qu'on peut alors renommer l'objet en RightService. D'ailleurs, je ne pense pas qu'il devrait exister de différence symbolique entre les XXXHelper et XXXService ou bien XXXManager; c'est mettre trop de pression sur le nommage, pour des termes extrêmement extrêmement proches.

la solution serait que la Collection instancie elle-même le RightHelper

Les composants ne doivent surtout pas instancier d'objet, car cela revient à squeezer totalement la DI. Si l'on veut supporter la DI, c'est un point important. Enfin, il faut bien voir qu'il existe déjà trois RightsHelper différents, que les composants peuvent voiloir utiliser:

• gestion des droits basées sur le SQL
• gestion des droits par API
• gestion open bar pour les tests

En conclusion, je ne vois pas de problème avec les droits en particulier sur l'archi actuelle, mais je préférerais une simplification du système de couche pour que les choses s'éclairsissent.

[nfaugout-lucca]

Je mets Repo et StorageService dans le même panier, car ils font tous les 2 partie de l'Infra.

Si on vire les Collections, alors on vire le côté "Rest driven" dans RDD. On pourrait le faire, mais il faudrait renommer la lib en LDDD pour "Lucca DDD" par ex !

Dans le code source que tu cites, y'a justement des collections, mais le mec appelle ça des services car il n'est pas dans une logique d'interrogation CRUD (REST) du Domain.

ex : https://github.com/dotnet-architecture/eShopOnWeb/blob/master/src/ApplicationCore/Services/BasketService.cs

Le BasketService gère les entités de type Basket. Pour fonctionner il utiliser un Repo qui gère des Basket, et il fait quasi exactement comme ce que nous on fait dans les collections, càd un CRUD qui transfère chaque verbe au Repo. ex DeleteBasketAsync qui appelle DeleteAsync sur le Repo !

Donc virer les Collections pour voir apparaître des xxService, non merci.

La grosse différence c'est que sur un xxService, tu peux faire, en plus du CRUD, un peu tout ce que tu veux.

Ici ils ont une méthode TransferBasketAsync qui fait un certain traitement. Dans une approche Rest, ce serait une sous collection qui gérerait des BasketTransfer et on ferait un POST dessus.

En résumé, une approche REST à base de Collection est censée permettre de mieux architecturer/découper le code métier. Si ça n'est pas clair ou que c'est compliqué à faire, c'est parce que c'est mal foutu dans RDD, mais je préfère qu'on essaie de corriger le tir plutôt que d'abandonner l'approche.