Re !

Et dans la vraie vie, le nouveau système X remplace l’ancien système Y… à 80% car migrer les 20% restants vers X coûte trop cher

T’as tout résumé…

Avant j’avais tendance à être assez extrême dans ma manière de coder et de voir l’architecture.

Désormais, je suis plutôt dans une optique de faire « au mieux en fonction des contraintes ».

Pour l’architecture hexagonal… J’ai parfois énormément de mal à dealer avec, notamment car elle rajoute une bonne couche de complexité là où certaines choses devraient être simples (notamment sur la DI).

De ce point de vue là, je t’invite à discuter avec Julien Topcu et Nicolas De Boose. J’ai beaucoup appris d’eux et je pense qu’ils auront plein de questions intelligentes à poser à tes questions 😉

Encore merci pour tes messages !

Au plaisir,

Alex

Hey 🙏

Merci pour ton message !

Je crains d’être influencé par des biais de confirmation, car notre architecture est le résultat d’une longue réflexion, avec des fausses pistes, des remises en questions et des réorientations.

La bonne architecture c’est celle qui correspond à tes besoins… C’est pour moi ce que le DDD essaye de transmettre, remettre le métier et ses besoins au coeur du code.

Et non pas se laisser dériver par un template ou une méthodologie rigide…

Honnêtement je ne suis vraiment pas certain de pouvoir vous aider.

Cet article est le fruit de 6 mois de recherche et je commence à peine à appréhender la chose dans sa globalité.

Bon courage pour vos recherches, et encore plus pour ton commentaire !

Ton article est vraiment ultra-détaillé et inspirant.
J’en suis à sa 4ème lecture, mais je sens qu’il y a encore de la richesse à en extraire.

Dans mon organisation, nous nous targuons d’être DDD avec une architecture en couches.
Pourtant, certains symptômes ne font penser que tel n’est pas le cas.

J’ai donc tenté de projeter notre architecte sur le modèle que tu proposes, mais des incohérences apparaissent.

Sûrement dues à nos divergences de langage (le langage commun est déjà très difficile à fixer au sein d’une organisation, c’est encore plus compliqué entre plusieurs organisations) mais aussi par des réflexes (pavloviens ?) développés de notre côté.

Je crains d’être influencé par des biais de confirmation, car notre architecture est le résultat d’une longue réflexion, avec des fausses pistes, des remises en questions et des réorientations.

Si je t’expliquais notre architecture actuelle, serais-tu disposé à la regarder avec l’œil du candide ?
Comprendre, avec l’œil et l’esprit non pollués par nos biais ?

Soyons clairs, je n’ai pas de budget pour lancer une telle étude via un contrat formel.
J’imagine ta contribution à une grosse paire d’heures (au pire 4).
Je ne peux te promettre que de la visibilité sur Twitter et LinkedIn (oui c’est peu).

Je comprendrais donc ton refus, sans aucun souci.

Bien à toi,

@jeff_bourges sous Twitter
https://www.linkedin.com/in/jean-fran%C3%A7ois-gabarren-25b38057/ sous LinkedIn

Excellent article qu’il me faudra relire plusieurs fois pour le contextualiser dans le vocabulaire de mon organisation et en extraire toute sa richesse.

Zoomons par exemple sur le modèle en couches, si tu le veux bien.

Ton découpage est : user interface + application + domaine + infrastructure
Dans notre langage corpo, nous découpons en : front-office (FO) + middle-office (MO) + orchestrateurs par domaine (ORK) + services élémentaires (SE) + back-office code métier et persistance (BO)
1 FO consomme 1 MO mais 1 MO peut être consommé par plusieurs FO
1 MO consomme 1 à n ORK, voire 1 à n SE directement.
1 ORK = 1 domaine, nous avons donc 1 ORK transverse. 1 ORK consomme 1 à n SE
1 SE consomme 1 BO

Dans un monde idéal, notre code métier devrait être uniquement dans les BO.
Mais dans la réalité, certaines règles métiers se trouve aussi dans le MO voire dans le FO ou l’ORK.
Exemples ?
Règles spécifiques à 1 FO d’une marque ou d’une population (parmi client final/courtier/agent/partenaireB2B…) => généralement codées dans le MO mais aussi parfois dans le FO. Cela dépend du nombre de FO connectés au MO et de la disparité des règles. C’est un de nos défauts 😉
Dans l’ORK, il peut y avoir des process métiers divergents de part l’historique des BO (le nouveau système d’assurance vie, celui d’avant, celui d’avant encore…).
Si l’urbanisation des SI était à 100% nous n’aurions pas ces verrues, mais cessions/acquisitions/rénovations etc… ne s’accompagnent pas toujours de cet effort.
Et dans la vraie vie, le nouveau système X remplace l’ancien système Y… à 80% car migrer les 20% restants vers X coûte trop cher

Au niveau de la data, les données vives du métier (les objets métiers comme proposition, contrat, prestation…) sont bien persistées dans les BO.
Mais nous avons aussi de la data dans les MO. Les paramètres applicatifs mais aussi les données de travail, celles collectées avant validation des objets métiers.

Du coup, j’ai du mal à faire matcher notre archi en couches et la tienne (surtout avec la vue Onion)

Et tout cas un grand merci pour ton partage !

Trop sympa, merci pour ton message Jean-Jacques 🙏

Merci pour le partage, je vais prendre le temps de regarder tout ça, notamment cette histoire de builder qui me paraît un peu confuse de mon côté !

Vladimir Khorikov je l’ai vu passer dans mes recherches, « always valid domain model » je l’avais lu, tellement important…

Je pense que ce qu’il veut dire c’est que l’exemple de la factory AnnonceFactory ressemble plus au pattern Builder que Factory.

Pour moi la factory (https://refactoring.guru/fr/design-patterns/factory-method) permet de retourner la bonne instance parmi plusieurs classes candidates,
alors que le builder (https://refactoring.guru/fr/design-patterns/builder) permet de créer un objet complexe par étapes,
étapes qui peuvent être guidées avec le pattern fluent builder (https://dzone.com/articles/fluent-builder-pattern).

Sinon super article avec pleins de source et ça c’est cool.

Je voudrais en partager une de plus le blog de Vladimir Khorikov alias https://enterprisecraftsmanship.com/
Sur ce blog il y a des articles qui sont pour moi des références comme par exemple :
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/
https://enterprisecraftsmanship.com/posts/always-valid-domain-model/

Merci pour ton commentaire super long et agréable 🙂

Je suis carrément d’accord avec toi sur le Design Tactique, car c’est avant tout du bon sens et des bonnes pratiques me concernant, je vais le préciser.

## Coût

Pour le coût, tu gagnes c’est sûr à la manière du TDD, mais je n’ai pas suffisamment d’expérience pour affirmer le contraire sur le DDD. En revanche tous les acteurs de la tech le disent, c’est plus couteux. Surtout j’imagine car les patterns stratégiques prennent beaucoup de temps, je pense que tu y gagnes sur les projets très complexes, sur les projets moyennement complexe si les méthodos de gestion de projet sont bien appliquées, a priori ça devrait aller. tu ne penses pas ?

D’autre part, si on parle du framework, qui fait parti de la couche infra, là aussi le découplage permet des mises-à-jour plus simples et donc plus rapide.

Alors moi la partie clean architecture et séparation du code métier je suis absolument convaincu. J’avoue que ça flirt bien avec le DDD et ses patterns 🙂

## Shared Kernel

Sur le Shared Kernel tu as sans doute raison, en revanche je serais curieux de voir comment tes bounded contextes interagissent entre eux ?
Pour le coup la gestion des utilisateurs je la délèguerais bien à un contexte externe en dehors de l’app, et si jamais il y avait besoin de discuter avec des classes internes, je le ferais sans doute grâce à une interface.

Si ton contexte `ExpeditionDeMarchandise` a besoin de l’adresse, en bon DDD, l’adresse de livraison devrait également se retrouver dans ce contexte.
Un Shared Kernel est quand `ExpeditionDeMarchandise` va directement utiliser les adresses des utilisateurs dans le contexte `User`.

Quand bien même l’utilisateur soit le même, j’aurais peut-être pensé à avoir 2 entités distinctes ici…

1 utilisateur qui passe 1 commande pour 1 point de livraison donné.

Afin de ne pas avoir d’info de commande dans le contexte User qui s’en balance. Je ne sais pas si c’est clair ou si je ne me suis pas égaré là 😀

## Core – Support – Generic

Tu entends quoi par couches ?

Ton exemple sur la comptabilité est super cool, je vais le faire remonter dans l’article car ça a beaucoup de sens.

## POO

Je vais creuser sur la FP, si il faut il y aura de beaux exemples !

## Clean / Onion architecture et DDD

T’as raison pour mon exemple sur le ORM, ça marche pas ! D’ailleurs j’aime pas l’AR non plus, j’en discutais au Web2Day hier avec un autre dev.

Je vais corriger ça, merci encore pour ta lecture 🙂

## Comment gérer les dépendances entre les couches ?

Cette partie était tellement longue et complexe que j’ai préféré ne pas trop l’aborder…

Mais ça va forcément fait l’objet d’un article un de ces quatre, c’est trop cool pour que je n’y aille pas 🙂

Encore MERCI pour ton commentaire super instructif !

Merci Charles !

Je ne connais pas du tout la méthode Prince, je vais me renseigner pour en parler via l’article sur les chefs de projet numériques 🙂

Merci Max ! Tu veux bien développer sur la diff Factory vs Builder ? 🙂

Hello Hervé !

Merci beaucoup pour ton message 🙂

Tu pourrais développer ? C’est grave intéressant ton exemple

Juste une remarque sur l’exemple donné pour les services :

« Par exemple, transférer de l’argent d’un compte à un autre.
Cette fonctionnalité ne peut pas se retrouver dans le compte qui débite ni celui qui crédite, par essence l’action doit se retrouver dans un service tiers. »

Pour moi, c’est plutôt l’exemple classique d’un aggregate « Transaction », puisqu’on voudra assurer l’intégrité du transfert.
L’utilisation d’un agrégat préserve la cohérence du système, en annulant le débit si le crédit échoue.

J’avoue que depuis que j’ai découvert le DDD, j’applique au moins le design tactique presque partout (sauf peut-être pour un PoC).
C’est une structuration de mon code que je trouve logique et en fin de compte plus simple.

Certes, peut-être pas indispensable de créer des couches ACL avec les composants tiers et on peut faire l’impasse sur d’autres éléments qui prennent un temps qui n’est pas forcément rentable, même sur le long terme.

Évidemment, pour des projets simple, le temps passé sur du design stratégique, est plus difficile à justifier.

## Coût

Pas forcément d’accord… Du moins sur le moyen et long terme.

Mais comme tu l’indiques plus loin, c’est un investissement.
Si pour une entreprise, il n’y avait pas de ROI… alors l’investissement n’en vaut clairement pas la peine.

Non… Je pense que le facteur « coût » est réellement à relativiser.
Tout comme pour le TDD.

À long et même à moyen terme, il y aura moins de bugs ET, de part la conception en contextes découplés (si c’est bien fait), l’impact d’un bug sera en général nettement moindre.
Le code de l’application sera également plus facilement à maintenir, encore une fois, grâce au découplage. D’une part, il sera plus simple de faire la mise à jour de dépendances tiers, parce que tu auras pris soin d’ajouter une couche d’abstraction qui est précisément un ACL (donc, la plupart des correctifs se feront dans cet ACL).
D’autre part, si on parle du framework, qui fait parti de la couche infra, là aussi le découplage permet des mises-à-jour plus simples et donc plus rapide.

Facilité de mise à jour == moins de dette technique (qui elle coûte très cher à terme)

Aussi, le code sera plus facile à adapter ou à étendre pour répondre à un nouveau besoin business.
Plus de vélocité, plus de flexibilité…. plus de ROI.

Bref…
On est d’accord que quand on se lance, le développement sera plus lent et coûtera un peu plus cher…
Mais rapidement les bénéfices engendrés par le DDD surpassent ce coût additionnel (comme j’ai dit, comme pour le TDD)

## Shared Kernel

L’impression que tu simplifies un peu trop ici.

Le Shared Kernel n’est pas « juste » un value object que tu voudrais partager…
En fait pour ce genre de Value Objects (comme `EmailAddress` que tu mentionnes), j’ai tendance à les mettre dans un module `Common` puisque ce sont des composantes, comme des dépendances, que tu risques d’utiliser un peu partout.

Le Shared Kernel est un peu plus que ça. C’est un Bounded Context dont une partie des composantes (entités, value objects, comportements, fonctionnalités, etc) sont partagés avec un ou plusieurs autres Contextes.
Dans beaucoup de cas c’est pour éviter de dupliquer du code (parfois parce que c’est pas si simple que ça, par exemple si lié à du Legacy)

Exemple simple, un Context `User` qui gère aussi bien l’authentication, que ses données (mails, adresses, numéros de téléphone, date de naissance etc).
Si ton contexte `ExpeditionDeMarchandise` a besoin de l’adresse, en bon DDD, l’adresse de livraison devrait également se retrouver dans ce contexte.
Un Shared Kernel est quand `ExpeditionDeMarchandise` va directement utiliser les adresses des utilisateurs dans le contexte `User`.

Le Shared Kernel a une série d’avantages, notamment du code non dupliqué, mais engendre aussi les problèmes liés au couplage fort… Encore plus si plusieurs contextes utilisent ce Shared Kernel.

## Core – Support – Generic

Il y a quelque chose qui me dérange ici… Peut-être que c’est un peu trop résumé…

Personnellement, je préfère voir ça comme des couches dans le Business et chacun des trois est composé de différents domaines et sous-domaines qui vont, *in fine*, se décliné en Bounded Contexts.

Après, ce qui va se trouver dans ces différentes couches va énormément dépendre du contexte.

Par exemple, un soft comptable se trouvera dans presque tous les cas dans le Generic Domain… Sauf si tu es une agence de comptabilité où le logiciel, même s’il est acheté, va se trouver au centre de ton Core Domain.

En fin de compte, ce n’est pas la solution technique qui définit si un composant est core, support ou generic… C’est le métier…
Et comme tu l’as indiqué, c’est le métier qui pilote.

## POO

La programmation fonctionnelle se prête aussi très bien du DDD, d’une certaine façon, même mieux…

## Clean / Onion architecture et DDD

Note: attention que Eloquent est basé sur l’Active Record, pas Doctrine qui se base sur le Repository Pattern (je ne suis personnellement pas un grand fan du AR)
Ça a un impact considérable si on voulait switcher…
Ceci dit, il y a des devs, Laravel évidemment, qui font du DDD avec Eloquent, mais IMHO il serait nettement plus simple de basculer carrément sur du simple PDO.

## Comment gérer les dépendances entre les couches ?

Pense que tu devrais parler de la gestion d’Events (Domaines et Applicatifs) ici.
IMHO, c’est la meilleure approche pour éviter le couplage.

À ce sujet, pour PHP, jette un œil à EcoTone :
Il aide aussi énormément pour la mise en place du CQRS dont tu parles plus bas…
Tout passe par des `Bus` (`QueryBus`, `CommandBus` &, évidemment le `EventBus` pour les événements).
Moi je kiffe.