> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md).
# W27-Conception par le domaine et interactions frontend-backend
#### **Réflexions sur la conception pilotée par le domaine**
**Comment garder un cœur stable dans un projet qui change vite, sans laisser la complexité devenir incontrôlable jusqu'à imposer une refonte ?** Nous perdons déjà des connaissances métier lorsqu'elles circulent dans l'équipe. Avec la croissance et le renouvellement des personnes, cela s'aggravera. **Ce cœur est la compréhension et l'abstraction du métier. Dans la conception logicielle, cela correspond selon moi à une approche fondée sur le domaine.**
Le backend est souvent conçu plus en détail et à plus long terme que le frontend. Un projet doit reposer sur une compréhension profonde du métier. Plus elle est précise et l'abstraction aboutie, meilleures seront maintenabilité et extensibilité. Sans conception, un backend ne peut parfois même pas démarrer.
Le frontend diffère. Nos plans techniques portent surtout sur des points techniques isolés et la réalisation des parcours. Nous décomposons encore trop peu le métier. **Notre conception reste essentiellement orientée vers les pages.** On voit rarement une abstraction métier guider les composants et les couches logicielles.
Dans un bon backend, le schéma des tables et la couche service restent relativement stables grâce à cette compréhension du domaine. L'activité marchande évolue vite, donc l'UI et les interactions aussi. Comment répondre au changement par un noyau stable et soutenir la croissance à moindre coût ? Je cherche la réponse dans le domain-driven design.
Prenons le paiement. La refonte de la version i organise l'application entre composants conteneurs, chargés de l'état et de la logique, et composants de présentation purs, reliant données et vues. La logique frontend n'est pas très complexe, mais le conteneur dépasse déjà six cents lignes. Il reste lisible, mais paiement par prêt, par placement et marketing vont l'épaissir. Il faut le découper. Selon quoi ? Le domaine. Le cœur est le traitement des moyens de paiement, à abstraire selon leurs propriétés métier. Chacun correspond à un fournisseur d'actif distinct et peut donc former un domaine, avec ses propriétés et comportements. Le paiement rapide possède une liste de cartes et permet d'en choisir une puis saisir un mot de passe. Le paiement par prêt possède échéances et montants, déclenche une reconnaissance faciale et récupère un contrat. Ces éléments fondamentaux sont relativement stables. Même si l'UI change, la couche de domaine reste. On peut même migrer de Vue à React en conservant le cœur.
Je n'ai pas moi-même assez travaillé cette conception auparavant. L'idée doit encore évoluer par les échanges et la confrontation.
#### **Quelques réflexions sur les échanges de données frontend-backend**
Par rapport au portefeuille, les paiements présentent des API clairement différentes. Pour le module de paiement, la liaison de cartes ou le règlement, les API frontend sont presque toutes conçues par page. Leurs relations suivent l'ordre des interactions humaines. Une réponse fournit l'URL de l'appel suivant, ses paramètres et tout le nécessaire à la page, presque jusqu'au HTML rendu.
L'avantage est de concentrer le frontend sur l'interaction, avec une responsabilité apparemment unique. Le backend contrôle souplement la suite des appels, choisit les services aval et renvoie les données sans négocier avec le frontend.
Le défaut est tout aussi clair : API, vue et parcours utilisateur sont étroitement couplés, ce qui fragilise l'extension. Ce mode fonctionne parce que la vue et le processus métier sont assez stables. Le paiement remplit effectivement cette condition. La méthode est peu générale, mais son choix initial répond sûrement à des considérations approfondies. Dans ce contexte, je ne peux encore la juger absolument bonne ou mauvaise ; il faut apprendre par la pratique.
**Dans le paiement rapide, l'API A fournit et détermine l'appel suivant. Le backend doit connaître la version frontend, par numéro de version ou par déploiement progressif de bout en bout fondé sur l'identifiant client.**