Super article !
Je m'y retrouve à peu près partout excepté quelques détails.
En particulier pourquoi ne pas séparer aussi les commandes par domaine métier et les avoir toutes dans Action ?
Petite remarque : totalement d'accord avec la couverture de test (tests fonctionnels en priorité, tests unitaires si besoin), mais ça aurait été intéressant d'avoir une explication supplémentaire sur ce choix.
Born before Internet, started as "webmaster", now supporting people mastering it.
I was shaped by XP methodology & DDD architectures. Open source enthusiast.
Merci beaucoup pour ton feedback Alan (et ton boulot sur API Platform!)
Structuration des commandes au plus près de l'opérationnel
En particulier pourquoi ne pas séparer aussi les commandes par domaine métier et les avoir toutes dans Action ?
Les commandes sont sur une limite floue parfois entre la couche application et la couche domain
Rien n'est parfait, ni même le métier. Néanmoins les commande handlers sont des actions métiers, des process métiers. Hors ces process, ces actions, sont amenés à travailler sur plusieurs domaines. En détail:
Cela est étroitement lié à mon paradigme très personnel qui ne fait absolument aucun discernement de la qualité des domains (Core, Supporting etc). Je prends l'exemple des coordonnées (address, phone, coordinates) qui sont très souvent, dans un "supporting domain" partagées dans les applications métiers. Certes nous n'avons pas besoin de respecter toujours le même niveau de règle métier, mais le niveau de "générisation" rend l'abstraction/concrétion dans chaque "domain" assez.... futile?
Ce que j'ai observé c'est que la tech offre de nouvelles possibilités au métier. On ne fait pas qu'automatiser (totalement ou partiellement) des process métiers existants. On permet de réinventer (assembler, enlever, fusionner) des process métiers grâce à la technologie. En conséquence, les domaines identifiés du métiers sont très souvent amenés à collaborer/coexister dans des nouvelles actions.
Autre point, je n'utilise pas de SAGA, et j'évite les AR "fumeux/couteux" trop puristes parfois. Je préfère synchroniser 2 AR (cross-domain) dans certains cas. Donc j'utilise la couche command handlers à ces fins économiques/pragmatiques.
La couche /Action/ coordonne la couche /Domain/ sans se conformer à la structuration du domaine. En d'autre terme: la couche "Application" est "au dessus" de la couche "Domain". Je ne sais pas si je suis très clair?
Lorsque j'ai beaucoup "d'actions", je peux les regrouper par catégorie d'actions, famille d'actions. Mais cette structuration est au plus proche de l'opérationnel du métier (donc plus loin de la taxonomie "domain").
Avec cette approche, la structuration de /Domain/ est tellement plus "facile". Dès que j'ai un partage de concept métier avec énormément de similitude au sein du même BC: je soulage l'implémentation en re-positionnant le concept partagé & partageable.
Je n'aime pas le terme "Action", mais je voulais éviter le conflit avec command-cli... En revanche je ne travaille pas avec API platform, donc je n'ai pas ce conflit "ADR" dans mon "framework". Je pense qu'il faudrait l'adapter dans le cas d'API platform (don't fight your framework)
Choisir la couche de tests en fonction de l'usage & de l'audience cible
Petite remarque : totalement d'accord avec la couverture de test (tests fonctionnels en priorité, tests unitaires si besoin), mais ça aurait été intéressant d'avoir une explication supplémentaire sur ce choix.
Il y a plusieurs valeurs sur un harnais de tests. La première, déjà très forte, est la stabilité du software/application. La seconde est la garantie des coûts de développement. De manière générale, sur une qualité de code acceptable, la problématique du cout du code réside dans la maîtrise & la connaissance de ce dernier (turn over des ressources humaines, mise jour de la documentation, cohérence des spécifications dans le temps, disponibilité des stakeholders? etc...)
En d'autres termes, les coûts de dev dans un dépot avec une qualité "ok": c'est une formule qui doit avoir comme base forte: le reverse engineering.
Je crois très fortement que les harnais de tests doivent couvrir cet aspect. En bref: un harnais de test doit répondre à ces deux questions:
Est-ce que ça fonctionne (encore) ?
Qu'est-ce que le code est capable de faire?
Le deuxième point est important: Car en lisant le "how/comment" (les tests) on doit voir surgir le "why/pourquoi". Pourquoi a-t-on codé cette classe, cette commande, ce projet.
J'ai été dans des boites "produits" et le DDD a été appliqué sur la construction de ces produits dont la source du code est propriétaire. Avec ces 2 critères, le harnais de test est naturellement orienté Behat sur la commande. Car la valeur des tests est de décrire le process métier et les différents scénario métiers pour lesquels le code a été prévu.
Dans le cadre d'open source, ou de projet a destination de développeurs, la couche unitaire devrait être très solide (là encore, question d'usage et d'audience pour valoriser le harnais de test). Si mon produit était essentiellement une API (Stripe?), il faudrait, dans cet autres cas, prioriser des tests à ce niveau.
Remarque: le DDD ne formalise aucune méthode organisationnelle. i.e: a aucun moment il n'est mention de la structuration ou du workflow de production. Le BDD (Behat est orienté BDD) lui structure l'approche collaborative métier, PO, Stackholder, ux, dev etc... j'utilise donc le BDD pour poser un cadre d'execution favorisant le DDD.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Super article !
Je m'y retrouve à peu près partout excepté quelques détails.
En particulier pourquoi ne pas séparer aussi les commandes par domaine métier et les avoir toutes dans
Action?Petite remarque : totalement d'accord avec la couverture de test (tests fonctionnels en priorité, tests unitaires si besoin), mais ça aurait été intéressant d'avoir une explication supplémentaire sur ce choix.
Merci beaucoup pour ton feedback Alan (et ton boulot sur API Platform!)
Structuration des commandes au plus près de l'opérationnel
Les commandes sont sur une limite floue parfois entre la couche application et la couche domain
Rien n'est parfait, ni même le métier. Néanmoins les commande handlers sont des actions métiers, des process métiers. Hors ces process, ces actions, sont amenés à travailler sur plusieurs domaines. En détail:
Cela est étroitement lié à mon paradigme très personnel qui ne fait absolument aucun discernement de la qualité des domains (Core, Supporting etc). Je prends l'exemple des coordonnées (address, phone, coordinates) qui sont très souvent, dans un "supporting domain" partagées dans les applications métiers. Certes nous n'avons pas besoin de respecter toujours le même niveau de règle métier, mais le niveau de "générisation" rend l'abstraction/concrétion dans chaque "domain" assez.... futile?
Ce que j'ai observé c'est que la tech offre de nouvelles possibilités au métier. On ne fait pas qu'automatiser (totalement ou partiellement) des process métiers existants. On permet de réinventer (assembler, enlever, fusionner) des process métiers grâce à la technologie. En conséquence, les domaines identifiés du métiers sont très souvent amenés à collaborer/coexister dans des nouvelles actions.
Autre point, je n'utilise pas de SAGA, et j'évite les AR "fumeux/couteux" trop puristes parfois. Je préfère synchroniser 2 AR (cross-domain) dans certains cas. Donc j'utilise la couche command handlers à ces fins économiques/pragmatiques.
La couche
/Action/coordonne la couche/Domain/sans se conformer à la structuration du domaine. En d'autre terme: la couche "Application" est "au dessus" de la couche "Domain". Je ne sais pas si je suis très clair?Lorsque j'ai beaucoup "d'actions", je peux les regrouper par catégorie d'actions, famille d'actions. Mais cette structuration est au plus proche de l'opérationnel du métier (donc plus loin de la taxonomie "domain").
Avec cette approche, la structuration de
/Domain/est tellement plus "facile". Dès que j'ai un partage de concept métier avec énormément de similitude au sein du même BC: je soulage l'implémentation en re-positionnant le concept partagé & partageable.Je n'aime pas le terme "Action", mais je voulais éviter le conflit avec command-cli... En revanche je ne travaille pas avec API platform, donc je n'ai pas ce conflit "ADR" dans mon "framework". Je pense qu'il faudrait l'adapter dans le cas d'API platform (don't fight your framework)
Choisir la couche de tests en fonction de l'usage & de l'audience cible
Il y a plusieurs valeurs sur un harnais de tests. La première, déjà très forte, est la stabilité du software/application. La seconde est la garantie des coûts de développement. De manière générale, sur une qualité de code acceptable, la problématique du cout du code réside dans la maîtrise & la connaissance de ce dernier (turn over des ressources humaines, mise jour de la documentation, cohérence des spécifications dans le temps, disponibilité des stakeholders? etc...)
En d'autres termes, les coûts de dev dans un dépot avec une qualité "ok": c'est une formule qui doit avoir comme base forte: le reverse engineering.
Je crois très fortement que les harnais de tests doivent couvrir cet aspect. En bref: un harnais de test doit répondre à ces deux questions:
Le deuxième point est important: Car en lisant le "how/comment" (les tests) on doit voir surgir le "why/pourquoi". Pourquoi a-t-on codé cette classe, cette commande, ce projet.
J'ai été dans des boites "produits" et le DDD a été appliqué sur la construction de ces produits dont la source du code est propriétaire. Avec ces 2 critères, le harnais de test est naturellement orienté Behat sur la commande. Car la valeur des tests est de décrire le process métier et les différents scénario métiers pour lesquels le code a été prévu.
Dans le cadre d'open source, ou de projet a destination de développeurs, la couche unitaire devrait être très solide (là encore, question d'usage et d'audience pour valoriser le harnais de test). Si mon produit était essentiellement une API (Stripe?), il faudrait, dans cet autres cas, prioriser des tests à ce niveau.
Remarque: le DDD ne formalise aucune méthode organisationnelle. i.e: a aucun moment il n'est mention de la structuration ou du workflow de production. Le BDD (Behat est orienté BDD) lui structure l'approche collaborative métier, PO, Stackholder, ux, dev etc... j'utilise donc le BDD pour poser un cadre d'execution favorisant le DDD.