Devoxxfr - DDD & Event sourcing avec la GDPR

20 avril 2018

_année_2018 _mois_avr. architecture ddd devoxx

source


La GDPR keskecé



La GDPR régit la manière dont les organisations travaillent avec les données des citoyens européens à partir du 25 mai 2018. C’est bientôt. Pour une entreprise qui ne respecte pas cette GDPR, l’amende est de 4% du chiffre d’affaire du groupe plafonné (peut-être) à 20 millions d’euros. Et ce sans compter les poursuites pénales et l’information des utilisateurs.


Les données des citoyens, c’est quoi ?




  • Nom

  • Adresse

  • Adresse IP

  • Les ensembles d’information permettant d’identifier un individu



Evidement, ça donne du travail …​





Et le DDD là-dedans ?



Saagie fournit une application de data governance. Cette appli, développée à l’arrache, est basé sur un paquet de CRUD qui manipulent les données en prod. Malheureusement, les problèmes liés à la GDPR ne sont pas adressables dans ce contexte.



Donc, il ne faut pas écrire du code contraint par la technique, mais plus par le domaine métier.


Et pour ça, il y a plusieurs éléments




  • Avoir un langage commun avec des termes qui sont utilisables par chacun et compris par tous.

  • Ne pas avoir un modèle unique : ça mène d’une part à des classes énormes, et d’autre part à des problèmes de compréhension

  • Les différents contextes dans lesquels s’expriment les modèles doivent être bornés



Pour obtenir ça, la méthode de design en couche avec des DAO, et de la base de donnée qui apparaît un peu partout est peu appropriée. Mettre le domaine au centre permet en revanche de rester "propre".


Et pour ça, se baser sur les événements peut être utile, parce que la plupart des modes sont d’une façon ou d’une autre événementiels.


Et pour construire le domaine et identifier les événements, la technique de l’event storming est assez utile.


Une fois ces événements identifiés, mettre le domaine au centre revient à mettre en place une architecture hexagonale.





Event sourcing



L’event sourcing, c’est le fait de définir les événements comme source unique de vérité. Avec ça, on peut reconstruire l'état des objets.


Ca apporte en plus


  • La testabilité

  • La gestion de version des données

  • Le debug et la reproductibilité

  • Le rollback (mais pas en supprimant le dernier événement)

  • La tracabilité

  • La recomposition des projections



En revanche, ça n’est qu’un pattern local, qui apporte évidement des inconvénients (comme par exemple le fait qu’il y aura toujours plus de données).





Questions




Comment gère-t-on les données personnelles dans un event store immuable ?


Les données personnelles ne doivent pas s’y trouver, sinon c’est foutu. Ou alors, on stocke une clé de chiffrage par utilisateur (en dehors de l’event store) et toutes les données de l’utilisateur sont chiffrées dans l’event store.






Mon avis



Les deux sujet sont intéressants, mais quel était le rapport ? En fait, il est dans les questions en fin de conférence, qui ont construit le lien.