Je cite l'auteur : "Pour résumer: le cercle vertueux du data mesh consiste en plusieurs étapes:

• délimiter un domaine de données ayant pour but de récupérer de la donnée et en extraire de l’information.
• ce domaine de données devient un nœud du maillage de données grâce aux principes directeurs d’échange, d’interopérabilité et de l’ontologie…
  tout ceci dans le but de produire des produits logiciels à forte valeur ajoutée pour le métier."

Tout est dans le titre

Tout est dans le titre

L'auteur donne son opinion sur l'intérêt ou non de découpler totalement les entités de l'ORM / Framework / ... Pour résumer, il faut que le modèle puisse être testé "en isolation" (sans base de données) mais y mettre des annotations (par exemple, Doctrine) n'est pas contre indiqué -> cela ne rend pas le modèle moins testable.

Tout est dans le titre

Un example de projet Symfony suivant une architecture hexagonale / DDD

Tout est dans le titre... Certaines conférences (comme celles sur le DDD par Meetic) ont l'air très intéressantes

D'autres conférences autour du domain driven design

Un résumé d'une conférence et d'un atelier auxquels a assisté l'auteur : ils traitent en particulier des contextes, et des heuristiques pour déterminer si le code doit être refactorisé

Tout est dans le titre

L'auteur explique comment il a refactorisé le code d'un jeu - tests, DDD, etc. Il est parti d'une conférence / live coding filmée

Des réflexions intéressantes sur l'utilisation de Doctrine pour faire du DDD