Lieu : Discord
Il n'est pas possible de s'inscrire pour cet évènement.
Pour bien débuter l’année et reprendre les bonnes habitudes nous vous proposons une soirée forum ouvert pour échanger et discuter. Vous voulez partager votre dernière lecture, dernière découverte, demander de l’aide sur un problème de votre projet ? Venez avec vos idées, vos envies, et nous construirons le programme de cette session ensemble.
Le forum Ouvert (en anglais Open Space ou Open Space Technology) est une méthode pour structurer des conversations et des conférences. N’importe qui peut proposer un sujet qu’il a envie d’aborder, qu’il le connaisse très bien ou pas du tout (c’est l’occasion d’apprendre). Des salles virtuelles seront alors créées pour chacun des sujets et les participants peuvent passer d’une salle à l’autre comme bon leur semble pendant la soirée.
Nous faisons cette session conjointement avec les Software Crafters de Lyon car ils ont de l’expérience dans ce genre d’évènements, et c’est l’occasion de leur poser des questions comme “C’est quoi le Software Craftmanship ?” ;)
Faire du DDD: orientation métier, mettre au centre le métier, distinguer le métier pour faire en sorte que l’application reste maintenable.
Contexte technique : pertinent de faire du DDD ? une question de besoin de performance ? Le critère est plutôt la complexité du métier. Le pattern “stratégie” peut permettre de bien délimiter les parties techniques ou simples et les parties complexes.
Impossible si pas de contact avec les experts métiers ? Beaucoup plus difficile mais pas impossible.
Faire du DDD pour de l’orchestration d’API ? Non pas forcément pertinent dans ce genre de situation.
Attention à ne pas lier la couche de persistence et le domaine métier, ce n’est pas compatible.
Des conceptions très différentes de ce qu’est le Software Crafstmanship. Un ensemble d’outils pour se simplifier la vie via du TDD, DDD… Le DDD est le boss de fin, complexe à appréhender. Le TDD est plus simple à appréhender mais attention : Test first != TDD.
Golden master (?)
The Mikado method : reprend la philosophie TCR (Test, Commit or Revert) https://blog.engineering.publicissapient.fr/2020/03/20/domptez-vos-refactoring-avec-la-mikado-method
Attention : éviter de prendre trop de temps à réfactorer (définir le scope, on peut se retrouver à découvrir des impacts cachés)
C’est non ! ;) Ou oui mais pour poser un logger avec une annotation.
On commence souvent par l’objet puis on découvre le fonctionnel mais c’est difficile car le paradigme est très différent. Lombok ? Ca incite a casser l’encapsulation. C’est pas un soucis de mélanger les paradigmes.
Avoir une base unique dans laquelle sont les données ? Pas top : les tests ne sont pas répétables + problèmes quand la structure change.
Utiliser les APIs de l’applicatif pour insérer les données (ou une API créée pour ça, sans règles de gestion) ? Inconvénient : nécessite de repartir à zéro à chaque fois.
Framework type DBUnit ou DBSetup + Flyway
Pour la base de test, plusieurs approches : H2 (in-memory) ou TestContainers
Pour initialiser la structure : parfois l’ORM peut s’en occuper, sinon Flyway/Liquibase ?
Plutôt se poser les questions suivantes ?
Les frameworks ne doivent pas être des contraintes. On peut continuer à faire de l’OOP. En gros : ça dépend xD Des fois des patterns sont utilisés sans forcément le savoir. Pratique surtout pour se comprendre entre pairs.
C’est possible :D Exemple concert de DDD : https://docs.google.com/document/d/1AnMeSI7RNA3zGQ2sKa0aKBThBeV6-CdDzn9fN1NGolQ/edit