Cet article de Sebastian Bergmann explique les différences entre les Data Transfer Objects (DTOs) et les Value Objects, et pourquoi l'immutabilité facilite les tests. Les DTOs, motivés techniquement, servent à transférer des données entre couches ou systèmes, tandis que les Value Objects, motivés par le domaine, représentent des concepts stables du domaine. L'immutabilité réduit la charge cognitive en test, car elle garantit que l'état des objets ne change pas. Les Value Objects, étant immuables, n'ont pas besoin de test doubles, contrairement aux DTOs qui peuvent en nécessiter si ils contiennent de la logique. L'utilisation d'objets immuables simplifie les tests en évitant les effets de bord indirects.
Cet article concerne l’importance des modèles de domaine typés en PHP, renforcés par des outils comme PHPStan et Psalm. L’auteur explique que la sécurité des types permet de préserver l’intégrité architecturale en rendant impossibles les états invalides (ex. : un montant négatif pour une classe Money). Les outils d’analyse statique détectent les violations de contrats, les fuites de nullabilité ou les dépendances architecturales non désirées, là où les tests unitaires peuvent échouer. L’article souligne que modéliser chaque concept métier (comme EmailAddress ou UserId) en tant que type dédié, et utiliser des règles personnalisées dans PHPStan/Psalm, transforme le code en un système fiable et auto-documenté. L’objectif : aligner l’intention des développeurs avec le comportement réel du code, réduisant ainsi la dette technique et les erreurs silencieuses. Une approche progressive est recommandée pour intégrer ces pratiques dans les projets existants.
Cet article aborde la cartographie des Value Objects avec Doctrine ORM, en utilisant les attributs PHP, les embeddables et les drivers PHP pour améliorer la conception des entités.
L’article souligne que la documentation officielle de Doctrine montre souvent des exemples d’entités anémiques (avec des getters/setters simples), mais propose une approche plus robuste en utilisant des Value Objects pour encapsuler la logique métier et garantir la cohérence des données. Il explique comment mapper ces objets en base de données avec Doctrine, notamment via :
- Les attributs PHP pour définir les métadonnées de mapping.
- Les embeddables pour intégrer des Value Objects directement dans les entités.
- Les drivers PHP pour une configuration plus propre et moderne.
L’objectif est de passer d’un modèle anémique à un modèle riche, où la validation et la logique métier sont encapsulées dans les Value Objects, plutôt que dispersées dans les services ou les setters. Une lecture utile pour ceux qui veulent optimiser leur architecture avec Doctrine et PHP 8+.
⚠️ Accès réservé aux membres Medium : Lien vers l’article (nécessite un abonnement ou un accès via le lien partagé).
Tout est dans le titre
Un résumé pour l'implémentation pratique des principes du DDD
... en utilisant un value object regroupant les paramètres entre eux
Un exemple de "code smell" et comment y remédier en utilisant des Value Object
Tout est dans le titre
Tout est dans le titre
L'auteur explique comment utiliser un value object comme fournisseur d'identité pour des entités, le tout dans le contexte d'une application Symfony / Doctrine. En prime on voit que cette approche est parfaitement compatible avec CQRS
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Un post qui complète les deux liens précédents, dans lequel l'auteur donne un exemple de Value Objects et de leur utilité dans un bon développement objet
La suite du lien précédent sur les "Value Objects" et quelques conseils pour la validation : où doit elle se trouver ?