Contexte

Gestion des droits

Une application de réservation dans les salons de coiffures
Il y a une différence entre un client et un gestionnaire
Approche 1 : class abstraite avec la gestion délégués aux classes filles
- Problème : expose les scenarii à tous les consommateur
Approche 2 :
- un shared kernel (un username)
- la gestion des rôles dans la couche infra
- chaque domaine définis les droits nécessaire (via les annotations, JAVA)
- la couche service via Aspect Oriented Programming va vérifier les droits
- Aucune gestion de rôle dédié
Approche 3 : injecter l’utilisateur à la commande
- Inconvéniant : peut surcharger le domain
Au cours de l’EventStorming Alberto Brandolini utilise beaucoup les Policy
RBAC vs ABAC
- RBAC force a créer beaucoup de rôles
- ABAC donne un sous ensemble d’actions restreint
- Les actions ne sont pas dans l’idp
- Il y a un mapping role <-> action côté applicatif
Cas exceptionel : “Roger a besoin de faire ça”
- Code smell à creuser => roole à nommer
Éviter l’utilisateur en mode God-object, couplé à tout avec le cycle de vie le plus court

L’approche peer-review intensive est contre-productive
Page 321 du Blue book prône le refactoring permanent
Avancer et refactorer au fur et à mesure de la compréhension du domain
Les refontes sont rarement bénéfiques lorsque ni les personnes impliquées, ni la méthodologie ne changent

“Il faut se surveiller pour ne pas donner une réponse technique quand il faut une réponse fonctionnelle” Arthur
“Il y a toujours un moment où le mouellon de la réalité vient s’écraser sur la tartelette de notre illusion de la réalité” Colin

ddd