[BACKEND] Refactorisation des repositories/uniformisation

[rv2931]

Les repositories on pas mal évolués pendant la saison 12 dataforgood et n'ont pas forcément suivi le pattern initial pendant la saison
Pour une mise au propre, il serait peut-être intéressant de remettre en cohérence tout ça mais pour ça il faudrait d'abord rappeler ou préciser les lignes directrices prévues initialement
D'après les discussions que j'ai pu avoir avec Amine, et ce que je pense en avoir compris, j'ai noté quelques axes de travail:

• A priori c'était un Domain Driver Design qui a été pensé au départ. Si on suit cette philosophie les classes Domain sont les classes de bases qui doivent se retrouver un peu partout, cela signifie que les repositories devraient recevoir et renvoyer exclusivement des classes Domain. Actuellement certaines fonctions renvoient ou prennent des DataFrame pandas ce qui contravient à ce principe. Pour ce besoin il me semble qu'il faudra prévoir des mappers selon les types comme il en existe déjà model_to_domain/domaine_to_model et donc dataframe_to_domain/domain_to_dataframe (A confirmer le principe)
• Pour coller au design pattern repositories, il est préconisé d'avoir une classe de base abstraite "AbstractRepository" pour tous les repositories (desgin pattern interface/repository). Puis en subclasse cette classe de base avec des classes toujours abstraites qui viennent spécialiser selon le type de stockage (SqlAlchemy, JSON, CSV,...) puis des sous-classes spécifiques à chaque Domain/Model afin d'y ajouter les fonctions propres aux Domain/Model. Une fois en place c'est assez pratique et propre, et surtout ça permet de simplifier grandement la création de répositories de tests (en évitant de mocker) à partir de jeux de fichier de tests en JSON, CSV, parquet, ou autres
• Au départ c'était le design pattern repository exclusivement (session générée par le construsteur de chaque répository) qui a été mis en place mais dans la pratique toutes les fonctions des repositories qui sont aujourd'hui utilisées reçoivent en argument la session créée préalablement afin de pouvoir réaliser plusieurs opérations sur la même session et pouvoir rollback la totalité des opérations en cas de problème. Donc dans les faits on a mis en place le design pattern UnitOfWork+Repository et pas seulement le Repository. Dans l'idée on pourrait éventuellement un peu plus l'assumer et utiliser la nomenclature UnitOfWork pour que ce soit peut-être un peu plus explicite et qui se justifie de toutes manières

Voilà pour les points que j'ai pu identifier en terme de mise au propre concernant les repositories. Tout ceci reste à discuter/valider