L'article explore une approche pour construire des applications en combinant les principes du Domain-Driven Design (DDD) et de l'architecture Clean. L'auteur propose de se concentrer sur les cas d'utilisation plutôt que sur les entités pures du DDD, en utilisant des cas d'utilisation pour orchestrer la logique métier inter-aggregats de manière claire et ciblée. L'article présente un exemple d'application simple avec des entités comme Student et Course, illustrant comment modéliser le domaine et gérer les relations entre les agrégats. Il préconise l'utilisation de l'ORM pour les opérations C(r)UD et des requêtes JDBC directes pour les requêtes impliquant plusieurs agrégats, s'inspirant des principes CQRS. Les cas d'utilisation sont transactionnels pour garantir la cohérence des états des agrégats. L'article conclut en soulignant les avantages de cette approche, notamment une meilleure compréhension du code et une facilité de test.
L'article présente les concepts clés du DDD - Domain Driven Development - avec des exemples d'application. C'est un bon résumé
L'auteur donne 3 raisons pour lesquelles l'appel à flush() dans les repositories est une mauvaise idée, notamment vis à vis du DDD. Il explique ce qu'il fait à la place.
L'article décrit une refonte pratique en C# pour transformer des modèles anémiques en modèles riches en comportement, en utilisant les principes du Domain-Driven Design. Il montre comment déplacer la logique métier des services vers les agrégats, améliorant ainsi la maintenabilité et la clarté du code. L'auteur illustre chaque étape avec des exemples de code avant et après la refonte, soulignant les avantages de cette approche.
L'article traite de la modélisation des invariants métiers dans le cadre du Domain-Driven Design (DDD) et de l'importance des agrégats (Aggregates). Il aborde la complexité de maintenir ces invariants, notamment lorsque les règles métiers deviennent plus complexes. L'exemple donné est celui d'une application e-commerce où la quantité de produits par commande est limitée. L'article explore deux approches pour gérer ces invariants : une approche simple où l'invariant est vérifié au niveau de l'objet LineItem, et une approche plus complexe nécessitant la dénormalisation des données pour garantir la cohérence éventuelle (Eventual Consistency). Cette dernière méthode implique de dupliquer certaines informations pour éviter des transactions lourdes et potentiellement bloquantes. L'article souligne également l'importance de la discussion avec les experts métiers pour définir les règles de gestion des invariants et introduit le concept de Job Queue pour assurer la mise à jour asynchrone et robuste des données. En conclusion, la complexité de la solution dépend de la volumétrie des données et des exigences métiers.
Tout est dans le titre
Tout est dans le titre
Un article très intéressant dans lequel l'auteur compare 2 styles de développement (piloté par les données versus piloté par les besoins métiers), et leur relation avec l'automatisation possible ou non de process métiers.
Tout est dans le titre
Tout est dans le titre
Un résumé pour l'implémentation pratique des principes du DDD
Dynamic Route loading in a non standard Symfony structure | by Anne-Julia Seitz | Aug, 2024 | Medium
Tout est dans le titre
Tout est dans le titre
Des réflexions intéressantes sur le DDD avec application au cas des entités Doctrine
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