L'Architecture hexagonale : Introduction

Découvrez l'architecture hexagonale : principes, exemples, intégration avec Spring Boot. Optimisez votre code pour des applications mobiles robustes.

Découvrons aujourd’hui l'univers captivant de l'architecture hexagonale. Cette approche du développement d'applications mobiles repose sur des principes fondamentaux, offrant une structure robuste et évolutive. Dans cet article, explorez les bases de l'architecture hexagonale, découvrez des exemples concrets sur GitHub et apprenez à l'intégrer avec Spring Boot. Optimisez votre code, maîtrisez l'inversion des dépendances et transformez votre façon de concevoir des applications mobiles.

Bienvenue dans le futur du développement logiciel !

Qu'est-ce que l'architecture hexagonale ?

L'architecture hexagonale redéfinit la conception des applications mobiles. À la base de cette approche novatrice se trouvent des principes clés, sculptant une structure en forme d'hexagone. Cette méthode se distingue par son agilité, son adaptabilité et son aptitude à créer des applications robustes. Découvrons les fondements de l'architecture hexagonale pour comprendre comment elle redéfinit le développement logiciel.

L'architecture hexagonale transcende les schémas conventionnels de développement logiciel. Imaginons-la comme une vue aérienne de votre application, où un hexagone représente le cœur, le noyau de votre système. Plongeons dans les détails de cette approche novatrice.

Au centre de cette structure, nous trouvons l'hexagone central. C'est le cœur, le noyau où réside la logique métier de votre application. Cet espace défini par l'hexagone représente l'essence même de ce que votre application offre à ses utilisateurs.

Les côtés de l'hexagone représentent les couches périphériques. Chacune de ces couches a un rôle spécifique dans l'interaction de l’application avec le monde extérieur. De la gestion des entrées/sorties à la persistance des données, ces couches entourent le noyau central, mais sans créer de dépendances directes avec lui.

Les interactions entre le cœur et les couches périphériques se font à travers des ports et adaptateurs. Les ports définissent des interfaces au sein du noyau, tandis que les adaptateurs fournissent des implémentations concrètes pour ces interfaces. Cette modularité offre une flexibilité essentielle, permettant à l'application de s'adapter sans altérer sa logique métier.

Enfin, l'inversion des dépendances est le principe qui gouverne l'architecture hexagonale. Plutôt que d'avoir des dépendances directes, le cœur de l'application dépend d'abstractions définies par les ports. Cette inversion crée un environnement flexible permettant des modifications sans impacter la stabilité du système.

Pour comprendre pleinement l'architecture hexagonale, explorons des exemples concrets. 

L'architecture hexagonale ne se contente pas de suivre les sentiers battus du développement logiciel. Imaginez-la comme une vue aérienne de votre application, où un hexagone représente le cœur, le noyau vibrant de votre système. Plongeons dans les détails pour rendre cette approche plus tangible.

Au cœur, l'hexagone central incarne la logique métier de votre application. C'est là que réside l'essence de ce que votre application offre à ses utilisateurs. Autour de ce noyau, les côtés de l'hexagone représentent les couches périphériques. De la gestion des entrées/sorties à la persistance des données, chaque couche a un rôle précis dans l'interaction de l'application avec le monde extérieur.

Exemples concrets

Imaginons une application de gestion de tâches où le cœur de l'hexagone représente la logique de gestion des tâches, des deadlines, etc. Les côtés de l'hexagone pourraient inclure une couche d'interface utilisateur, une couche de persistance des données, et une couche de services externes.

Les interactions entre le cœur et les couches périphériques s'effectuent à travers des ports et adaptateurs. Les ports définissent des interfaces au sein du noyau, tandis que les adaptateurs fournissent des implémentations concrètes pour ces interfaces. Cette modularité offre une flexibilité essentielle, permettant à l'application de s'adapter sans compromettre sa logique métier.

Supposons que le port "GestionTâchesPort" définisse les opérations nécessaires à la gestion des tâches. L'adaptateur "GestionTâchesAdapter" fournirait l'implémentation concrète de ces opérations, interagissant avec la base de données et les services externes.

Enfin, l'inversion des dépendances règne en maître dans l'architecture hexagonale. Plutôt que des dépendances directes, le cœur dépend d'abstractions définies par les ports. Cette inversion crée un environnement souple, permettant des modifications sans secouer la stabilité du système.

Plutôt que d'avoir des dépendances directes vers la base de données, le cœur dépendrait d'interfaces définies dans le port "PersistancePort", laissant les détails d'implémentation à l'adaptateur "PersistanceAdapter".

En résumé, l'architecture hexagonale offre une vision stratégique du développement logiciel. Elle place la logique métier au centre, entourée de couches flexibles facilitant l'interaction avec le monde extérieur. Cette approche, avec son hexagone central et ses principes fondamentaux, ouvre la voie à des applications mobiles robustes, adaptables et pérennes.

Les principes de l'architecture hexagonale

L'architecture hexagonale repose sur des fondements solides, formant une structure en forme d'hexagone pour créer des applications mobiles robustes. Décortiquons les principes clés qui définissent cette approche innovante :

  • L'architecture hexagonale est structurée en couches fondamentales. De la couche d'infrastructure à celle de persistance, chaque strate joue un rôle crucial. Cela offre une organisation claire, favorisant la stabilité et la modularité.
  • Le point d'entrée représente l'accès initial à l'application, tandis que la logique métier dicte son fonctionnement interne. Cette dualité assure une expérience utilisateur fluide, équilibrant l'interaction extérieure avec la logique interne.
  • Fondamentale à l'architecture hexagonale, l'inversion des dépendances renverse les schémas traditionnels. Cette approche permet à l'application de s'adapter aux changements sans compromettre sa stabilité. Elle crée un environnement où la logique métier guide les détails d'implémentation.

Mise en pratique de l'architecture hexagonale

Découvrons comment concrètement mettre en œuvre l'architecture hexagonale dans le développement d'applications mobiles. Plongeons dans des exemples tangibles pour comprendre son impact réel.

Explorez un exemple concret sur GitHub où le code source d'une application est dévoilé. Chaque composant, de la couche d'infrastructure à la couche de persistance, est clairement défini. Visualisez comment ces éléments s'entremêlent pour former une structure cohérente. Cette transparence simplifie le processus de développement, permettant une compréhension facile et une évolution efficace de l'application.

L'intégration pratique de l'architecture hexagonale est facilitée avec Spring Boot. Cette union offre une approche concrète pour développer des applications mobiles robustes. Elle simplifie la gestion des dépendances et maintient la flexibilité, permettant aux développeurs de se concentrer sur la création plutôt que sur des considérations techniques. 

L'architecture hexagonale dans le contexte du Domain-Driven Design

Plongeons dans la synergie puissante entre l'architecture hexagonale et les principes du Domain-Driven Design (DDD), développant ainsi des applications mobiles de plus grande qualité.

L'architecture hexagonale et le Domain-Driven Design (DDD) fusionnent harmonieusement pour définir des modèles de domaine robustes offrant ainsi une approche complète du développement logiciel.

Lorsque nous plongeons l'architecture hexagonale dans le contexte du Domain-Driven Design (DDD), une collaboration symbiotique émerge. Ces deux approches, axées sur la compréhension profonde du domaine métier, se renforcent mutuellement.

1. Collaboration Harmonieuse

Imaginons une application de commerce électronique. Dans l'architecture hexagonale, le cœur de l'hexagone représente la gestion des commandes, des transactions, et des stocks, constituant la logique métier centrale. Dans le contexte du DDD, ces entités deviennent les agrégats du domaine, chacun avec son propre cycle de vie et ses règles métier spécifiques. Ainsi, l'hexagone central et les agrégats du DDD collaborent harmonieusement pour façonner le modèle de domaine.

2. Réflexion sur le Contexte Limité

Poursuivons avec la réflexion sur le contexte limité du DDD. Supposons que notre application de commerce électronique ait également un module de gestion des utilisateurs. Dans l'architecture hexagonale, cela devient une autre zone centrale, avec ses propres ports et adaptateurs. Dans le contexte limité du DDD, ce module représente son propre sous-domaine avec ses règles métier distinctes. Cette approche permet une séparation claire des préoccupations et une meilleure compréhension du modèle de domaine, alignant ainsi l'architecture hexagonale avec les principes du DDD.

3. Alistair Cockburn et les Fondements

Alistair Cockburn, un pionnier du Domain-Driven Design, souligne l'importance de définir des interactions précises entre les entités du domaine. Dans l'architecture hexagonale, cela se traduit par la définition précise des ports et adaptateurs, offrant une interface bien définie pour chaque interaction. Cette synchronicité entre les principes de Cockburn et l'architecture hexagonale garantit une compréhension approfondie du domaine et une mise en œuvre logicielle qui reflète fidèlement la réalité métier.

L'architecture hexagonale et le Domain-Driven Design forment une alliance puissante. En utilisant des exemples concrets, nous avons vu comment ces approches complémentaires collaborent pour créer des modèles de domaine clairs, des contextes limités bien définis, et des applications mobiles riches en fonctionnalités métier.

Nos conseils pratiques et astuces

Explorez des conseils concrets et des astuces judicieuses pour optimiser l'utilisation de l'architecture hexagonale dans le développement d'applications mobiles.

Dans la mise en œuvre de l'architecture hexagonale, privilégiez la clarté. Des noms de classes explicites aux commentaires informatifs, assurez-vous que chaque composant de votre application est compréhensible. La transparence facilite la collaboration et la maintenance à long terme.

Investissez dans des tests unitaires approfondis. L'architecture hexagonale favorise la testabilité, alors profitez-en. Des tests solides garantissent la stabilité de votre application et facilitent l'identification rapide des problèmes potentiels.

Accompagnez votre code d'une documentation complète. Décrivez les choix architecturaux, les interactions clés, et les modèles de domaine. Une documentation détaillée facilite l'intégration de nouveaux membres dans l'équipe et assure une compréhension globale du projet.

Soyez sélectif quant aux dépendances. Limitez-vous aux dépendances nécessaires pour éviter la complexité inutile. Une architecture hexagonale bien conçue privilégie la simplicité, ce qui facilite la maintenance et l'évolutivité.

Adoptez une approche itérative. L'itération continue associée au réajustement est essentielle. Recueillez les retours, identifiez les améliorations possibles, et évoluez constamment. Cette approche flexible s'aligne parfaitement avec les principes de l'architecture hexagonale.

L'architecture hexagonale se révèle comme une approche incontournable pour le développement d'applications mobiles. Avec ses principes solides, sa mise en pratique transparente, et sa synergie avec le Domain-Driven Design, elle offre une solution robuste et flexible.

Priorisez la clarté, investissez dans des tests unitaires approfondis, documentez judicieusement, évitez les dépendances superflues, et adoptez une approche itérative pour un succès continu.

En embrassant l'architecture hexagonale, vous développez des applications mobiles plus résilientes et créez une base pour l'innovation future. Restez agile, apprenez constamment, et évoluez avec votre application.

L'architecture hexagone est le socle sur lequel repose l'avenir du développement logiciel mobile.

Sommaire
Nos autres catégories
Partager sur :
Nos autres catégories
Partager sur :

Ne manquez rien
Abonnez-vous à notre newsletter

Notre newsletter tous les mois :
Je m'abonne
Merci ! C'est dans la boîte :)
Oops! Something went wrong while submitting the form.

Nos experts vous parlent
Le décodeur

DORA Metrics : utiliser la technologie pour piloter la valeur du business
11/4/2023

Les métriques DORA sont devenues incontournables pour évaluer et améliorer la performance des équipes DevOps. Ces indicateurs clés permettent de mesurer la rapidité, la stabilité et l'efficacité du processus de développement et de déploiement logiciel.

Dans cet article, nous analyserons en profondeur ces métriques, leurs implications pour les équipes techniques, et comment les implémenter efficacement. Que vous soyez CTO, membre de la DSI ou développeur, comprendre et utiliser les métriques DORA est essentiel pour optimiser vos opérations et garantir la livraison continue de valeur à vos utilisateurs finaux.

Voici un exemple de projet pour lequel nous suivons les DORA Metrics chez Yield Studio :

Pour qui ?

Avant d’attaquer le sujet concrètement, commençons par définir la cible de ces métriques.

Contre toute attente, elles sont transverses. Moyennant une bonne application, les métriques peuvent être consultées par la DSI , le CTO ou le management top level mais elles sont belles et bien pilotées par les équipes techniques. Ces métriques sont également essentielles pour les équipes DevOps qui cherchent à améliorer leur collaboration et leur performance globale.

Pourquoi ?

Assez simplement ce sont des métriques, des KPI, des nombres qui portent plus ou moins de contexte et permettent de quantifier la performance des équipes techniques (software team). Bien souvent, la littérature retient 4 métriques au total bien qu’il en existe une 5ème qu’on évoquera rapidement mais qu’on exclura par la suite.

Elles fournissent des informations précieuses sur la rapidité avec laquelle les équipes DevOps peuvent répondre aux changements, le temps moyen pour déployer du code, la fréquence des itérations et les échecs.

Ces indicateurs sont cruciaux pour :

  • Fournir des estimations de réponse réalistes
  • Améliorer la planification du travail
  • Identifier les domaines à améliorer
  • Consolider les investissements techniques et en ressources

Les 4 Principales Métriques DORA

  1. DF (Deployment Frequency)

    Il s’agit de la fréquence à laquelle du code est déployé en production sur une période de temps. Précisions tout de même que le code doit être déployé avec succès. S’il faut rollback chaque déploiement ça compte pas.
    C’est également un indicateur de fréquence à laquelle les ingénieurs délivrent de la valeur aux utilisateurs finaux.

    Plus elle est élevée et plus les utilisateurs profitent vite des incréments de code.

    A titre indicatif, une valeur moyenne est de 1 déploiement par semaine.

  2. MLTC (Mean Lead Time for Changes)

    Il s’agit du temps moyen entre le premier commit et le déploiement en production.
    Souvent les développeurs doivent repasser plusieurs fois sur le code produit initialement suite notamment à la re-lecture par d’autre développeurs ou pour apporter des corrections demandées par le product owner.

    Dans un autre domaine, cette métrique correspond au temps d’immobilisation (stock).

    A titre indicatif, une valeur moyenne est de 1 semaine.

  3. CFR (Change Failure Rate)

    Il s’agit du pourcentage de déploiements en production qui causent un problème.

    On le calcule en divisant le nombre d’incident par le nombre de déploiements.

    A titre indicatif, une valeur moyenne se situe entre 16 et 30%.

  4. MTTR (Mean Time To Recovery)

    Il s’agit du temps moyen nécessaire pour réparer un problème et remettre le système dans un état stable.

    A titre indicatif, une valeur moyenne se situe à moins d’un jour.

Une Cinquième Métrique : La Fiabilité

aSouvent oubliée, cette métrique est plus orientée DevOps/SRE et se base sur des objectifs opérationnels/contractuels (SLA). Elle mesure la capacité à atteindre ou dépasser ces objectifs, fournissant une perspective supplémentaire sur la performance opérationnelle.

Comment mettre en place ces métriques ?

Il existe plusieurs approches pour mettre en places ces métriques. La plus simple reste de s’appuyer sur un outil qui les intègre déjà, comme LinearB.

Source: LinearB https://linearb.helpdocs.io/article/7ck7fu67am-metrics-dashboards-dora-metrics

Qu’importe le flacon l’outil, pourvu que vous commenciez à mesurer.

Et si cela ne marche pas dans mon cas  ?

“Oui mais moi ma feature est complexe, il me faut plusieurs semaines pour terminer, je vais biaiser la moyenne gneu gneu gneu …”

  • Découpe ta feature et utilise des feature flags pour délivrer de façon incrémentale.

"Oui mais c’est long de tout tester à chaque fois gneu gneu gneu …"

  • Sois flemmard et écris des tests pour automatiser ton job.

TL;DR

Les métriques DORA sont des indicateurs de la production de valeur produit/business.

Elles sont applicables aux DevOps comme aux développeurs et intéressent toute la software team. Pour être pertinentes, les développeurs doivent être acteurs du pilotage de ces métriques car aucun manager ne pourra les forcer à cela.

Une observation macro est que les DORA poussent naturellement à réduire les incréments de code. En effet, en envoyant moins de code à chaque déploiement, on mitige le risque et les déploiements sont naturellement plus rapide.

Notons aussi que les DORA ne se suffisent pas à elle même, elles appellent à d’autre bonnes pratiques que sont le respect du manifeste agile https://agilemanifesto.org/, l’ajout de tests ou encore les principes LEAN de Toyota.

Enfin, avis aux néophytes avides de tableau Excel, si les DORA permettent de quantifier un problème, une lame de fond, elles ne le qualifie pas pour autant. Le sujet central reste un sujet humain, on parle d’équipes d’homme et de femme qui ont leur code, leur cohésion, leur problématique propre. Piloter uniquement les DORA pour présenter un Excel “tout au vert” serait naïf et pourrait compromettre l’équipe ciblée.

Et Yield Studio là dedans ?

Selon la classification mentionnée en annexe Yield Studio se situe en “high performer” et s’améliore en continu pour atteindre prochainement le grade “elite”. Et vous, vous vous situez où dans ce tableau ? Aujourd'hui les DORA Metrics nous permettent de garantir une réelle qualité auprès de nos clients dans les projets qu'ils nous confient.

Source

Valeurs indicatives pour chaque DORA metric

Source: Google Cloud https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en

Développer avec le database branching
14/12/2023

Le database branching est une approche d’organisation de base de données qui permet de reproduire la dynamique et le fonctionnement des branches Git.

On va alors pouvoir à partir d’une base de données appelé “master” pouvoir dupliquer une “branche” avec un certain nom. Cette nouvelle base de données se vera hériter des données ainsi que des migrations de la branche source.

Les cas d’usages de ce principe sont multiples et variés. Si nous reprenons l’analogie avec Git flow, lorsque vous allez créer une nouvelle branche de feature, vous serez amené à devoir développer puis appliquer une migration de données ou bien tout simplement altérer les données contenues dans cette base. Elle devient à partir de là un bac à sable tout en partant d’un environnement déjà prédéfini.

Grâce à la nouvelle base de données mise en place pour votre feature, vous n’allez impacter aucun environnement de production / staging / dev mis en place et accessible par tous les développeurs.

Votre base de données sera alors unique et éphémère, une fois la feature terminée, celle-ci pourra être supprimée.

Elle peut aussi servir de base de données temporaire pour une démonstration client, alimentée de données bien précises pour cette dite démonstration.

Pour terminer cette introduction, j’ajouterai que le database branching est présent avant tout pour améliorer la “DX” des développeurs au quotidien.

Pourquoi ne pas alors simplement produire une base de données sur ma machine ?

Il est autant possible que l’infrastructure du projet mette à disposition un cluster de base de données sur un serveur ou bien qu’un développeur puisse créer son cluster sur sa machine.

Avec un provisionnement type Docker vous pouvez déployer rapidement une base de données sur votre machine avec un script de seeding permettant d’alimenter cette base en données. Cependant, vous allez perdre une composante essentielle au database branching qui est la synchronisation de la branche Git avec les données.  En effet, si vous êtes plusieurs développeurs à intervertir sur cette feature / environnement, aucune manipulations supplémentaires ne sera à faire lors du passage sur la branche Git. Vous récupérez la base de données déjà préparée par le précédent développeur.

Vous allez aussi avoir la problématique d’espace disponible sur votre machine, si vous travaillez sur plusieurs branches en même temps, cela implique de pouvoir posséder un conteneur d’une base de données unique par branche. Donc, une grande quantité de données en local.

Comment s’intègre le Database branching dans le workflow du développeur

Comme n’importe quel outil s’ajoutant sur une stack d’un projet, le database branching viens complexifier quelques aspects techniques de celui-ci.

Alors, il est nécessaire d’automatiser le maximums d’aspects du database branching afin de ne pas augmenter le nombre de tâches à réaliser par les développeurs lors de la création d’une nouvelle feature.

En laissant certaines tâches manuelles, nous risquons de frustrer nos collègues développeurs. En effet, il est très facile d’oublier d’exécuter  une certaine commande après un changement de branche.

Dans la deuxième partie de l’article nous nous intéresseront à réaliser un environnement de développement fluide avec l’exemple d’une stack web.

Je dirai alors que le database branching idéal est celui qui est complètement transparents pour les développeurs.

Dans la finalité ce principe est plus ou moins une idéologie, le degrés de l’implémentation peut dépendre de l’envergure du projet et du nombre de développeurs.

Tutoriel: Mise en place du database branching sur une stack Typescript, Prisma

Initialisation du projet et de la base de donnée

La première étape de ce tutoriel sera de se munir d’une base de données avec un utilisateur ayant l’autorisation de créer des database supplémentaires.

Voici plusieurs providers proposant ce service:

Actuellement nous utilisons une base de données hébergée Aurora Serverless hébergée sur AWS déployée depuis Terraform avec le module suivant.

Pour la suite de ce tutoriel nous avons choisis d’utiliser une base de données PostgreSQL. Il est aussi tout à fait possible de l’intégrer sur une base de données MongoDB, MySQL, …

Pour passer rapidement sur les étapes d’initialisation du projet TS avec Prisma je vous redirige vers la documentation officielle de Prisma.

Après toutes ces étapes vous devriez avoir dans la racine de votre projet un fichier d’environnement nommé .env qui possède une url de base de données DATABASE_URL.

À présent nous pouvons remplacer cette url par celle de notre base de données  provisionnée un peu plus haut.

DATABASE_URL="postgresql://gabriel:password@db-branching.cluster-xxxxxxx.eu-west-3.rds.amazonaws.com:5432/master?schema=public"

La database pointée (master dans ce cas-là) importe peu, elle sera mise à jour par  la suite automatiquement.

Automatisation du changement de branche

Afin de faciliter le passage sur une nouvelle base de données à chaque changement de branche git, il est possible de créer un hook sur le projet git, qui sera exclusivement lancé lors d'une commande git checkout.

Pour celà nous utiliserons un outil facilitant la création de hook git nommé Husky.

Voici les commandes d’installation que vous pouvez retrouver dans la documentation officielle:

Cette dernière commande va alors créer un script bash dans le dossier suivant.husky/post-checkout.

On ajoutera ces trois lignes de bash permettant de récupérer la branche git lors d’un checkout et de mettre à jour le fichier .env

Et voilà !

Maintenant à chaque changement de branche en local votre .env sera mis à jour automatiquement.

Il est possible d’aller plus loin en ajoutant l’application automatique des migrations de la base données et/ou le seeding de data.

L’Architecture Hexagonale sur un projet Web + Mobile (Partie 1 sur 5)
27/2/2024

Hola, je vais vous présenter le début d'une nouvelle série d'articles dédiées à la construction d'un projet Web et Mobile en mettant à profit l'Architecture Hexagonale. Durant toute cette série, nous allons explorer comment la logique métier peut être partagée et gérée efficacement à travers différentes plateformes.

Nos objectifs

Nous allons avoir plusieurs objectifs à atteindre au fil de ce projet :

  • Apprendre comment développer une application Web et Mobile à la fois en mettant à profit les technologies modernes (Nx, Expo, Remix, Vitest, etc.)
  • Comprendre les principes de l'Architecture Hexagonale et comment l'appliquer pour optimiser le partage de la logique métier
  • Gagner en compétence et en confiance pour lancer votre propre projet multi-plateforme, tout en développant une base de code propre et maintenable

La structure de la série

Comme je l'ai dis au début de ce premier article, ce projet donnera lieu à une série d'articles qui sera structurée de cette manière :

  • Partie 1 (cet article) : présentation du projet et mise en place d'un monorepo avec Nx
  • Partie 2 : développer sans UI avec l'Architecture Hexagonale
  • Partie 3 : partager de la logique métier et des composants entre le Web et le Mobile
  • Partie 4 : refactor serein avec les tests et l'Architecture Hexagonale
  • Partie 5 : déploiement Web et Mobile avec Netlify et EAS

Le projet

Le projet qui va nous aider à mettre en avant l'Architecture Hexagonale est un outil de gestion de budget que l'on appellera broney (le bro qui t'aides à gérer ta money 😎). Cet outil sera composé de deux applications, une première, web, développée avec Remix et une deuxième, mobile, développée avec Expo. Nous aurons donc 2 applications React et React Native avec un package TypeScript qui contiendra la logique métier partagée entre ces 2 applications.

Stack

La Stack que j'ai choisi est très subjective, on y trouve quelques frameworks qui mérite selon moi plus de lumière (Remix notamment et Nx face à NextJS et Turborepo). Néanmoins il est important de comprendre que peu importe les frameworks et libraires utilisées, le coeur de l'application sera complètement agnostique et réutilisable dans n'importe quel contexte.

Fonctionnalités

Pour mettre en avant l'Architecture Hexagonale nous allons avoir besoin de développer quelques fonctionnalités pour avoir de la logique métier. Nous allons nous focus sur les fonctionnalités suivantes :

  • Mettre en place le storage : react native mmkv pour le mobile et localStorage pour le web
  • Gérer les catégories : lister, ajouter, modifier et supprimer
  • Gérer les portefeuilles : lister, ajouter, modifier et supprimer
  • Gérer les transactions d'un compte : lister, ajouter, modifier et supprimer
  • Authentification avec Supabase
  • Dynamiser toute l'app avec Supabase

Modèle de données

Pour mettre en place les fonctionnalités nous allons avoir besoin des entités suivantes :

  • Wallet, un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€)
  • Category, des catégories servant à préciser le contexte des transactions faites (par exemple on a les catégories "Maison", "Restaurants" et "Divertissements")
  • Transaction, les transactions sont liées à un portefeuille et à une catégorie pour savoir où l'argent est transférée (par exemple on a une transaction du portefeuille "Compte Principal Julien" de 50€ sur la catégorie "Restaurants")

Mise en place du monorepo avec NX

Initialisation du projet

Nous allons utiliser les commandes de Nx pour initialiser notre projet.

➜ npx create-nx-workspace@latest

✔ Where would you like to create your workspace? · broney
✔ Which stack do you want to use? · none
✔ Package-based monorepo, integrated monorepo, or standalone project? · package-based
✔ Enable distributed caching to make your CI faster · Yes

Avec cette commande nous avons le projet Nx configuré de base et sans libs pour le moment. Nous allons travailler avec le style Package-Based Repos qui nous offre plus de liberté en limitant le couplage avec Nx si jamais on souhaite changer facilement d'outil de monorepo. Cela permet également d'avoir des node_modules différents pour chaque app ou lib du projet. En savoir plus sur les différents style d'implémentation de Nx.

Création de la lib core

Nous allons maintenant ajouter notre première lib, la plus importante : core. En effet, c'est dans cette lib que nous allons mettre notre Architecture Hexagonale et la logique métier qui sera utilisée par nos applications Web et Mobile.

➜ nx g @nx/js:lib libs/core

✔ Which unit test runner would you like to use? · vitest
✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · rollup

Cette commande nous a généré une lib avec le framework de test Vitest, une config eslint et prettier que l'on peut adapter à nos preferences que je ne détaillerai pas ici.

Il est possible de compiler notre lib avec la commande nx core build et d'executer les tests avec nx core test.

Mise en place de la CI

Maintenant que nous avons les tests setup ainsi que prettier et eslint, il est pertinent de mettre en place une CI pour avoir du feedback régulier sur la bonne tenue du code. Pour la CI nous allons simplement suivre la documentation de Nx et utiliser les GitHub Actions.

Nous allons donc simplement ajouter un fichier .github/workflows/ci.yml assez simple qui peut être étoffé.

name: CI
on:
	push:
	branches:
	- main
	pull_request:

jobs:
	main:
		runs-on: ubuntu-latest
		steps:
			- uses: actions/checkout@v4
				with:
					fetch-depth: 0
			# Cache node_modules
			- uses: actions/setup-node@v3
				with:
					node-version: 20
					cache: 'yarn'
			- run: yarn --no-progress --frozen-lockfile
			- uses: nrwl/nx-set-shas@v4.0.4

			- run: npx nx format:check
			- run: npx nx affected -t lint,test,build --parallel=3

Cette simple CI permet vérifier le bon formatage prettier, d'effectuer les validations eslint et de build et de s'assurer que les tests sont sans erreurs.

Structure du projet

Rentrons plus en détails dans ce que l'on vise comme structure de projet une fois les apps mise en place et notre lib core développée avec l'architecture hexagonale.

- apps

    - mobile : notre application React Native développée avec Expo
    - web
: notre application React développée avec React

- libs
    - ui
: nos composants React et React Native utilisés par les apps web et mobile
    - tailwind
: notre configuration tailwind utilisée par les apps web et mobile ainsi que la lib ui
    - core
: notre architecture hexagonale qui contient le coeur de notre application et toute la logique métier réutilisable par les apps web et mobile

Pour aller plus loin, on peut très bien envisager d'avoir une app en plus pour un Storybook.

La lib qui va nous intéresser et la lib core évidemment. Elle sera structurée de cette manière :

- libs
    - core
         - src
              - wallet
                   - tests
                        - wallet.service.test.ts
: la logique métier testées
                        - wallet.test.ts
: les règles métiers testées
                   - domain
                        - wallet.ts
: l'entité qui représente les portefeuilles et qui contient des règles métiers
                        - wallet.repository.ts
: le contrat qui détermine comment manipuler l'entité pour lister, ajouter, etc.
                        - wallet.service.ts : le service qui consume une implémentation de contrat

                   - infrastructure
                        - in-memory-wallet.repository.ts
: une implémentation du contrat
                        - local-storage-wallet.repository.ts
: idem
                        - supabase-wallet.repository.ts : idem
                   - user-interface
                        - wallet.store.ts :
un store zustand vanilla, utilisable dans n'importe quel environnement javascript et qui sera utilisé dans nos apps
              - category
                   - ...
           - ...

Nous verrons le contenu de chaque fichiers ainsi que les détails du fonctionnement de ces derniers dans le prochain article !

Conclusion

Nous avons terminé le premier article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette première partie nous avons vu comment mettre un place un monorepo et nous avons pourquoi et comment ce monorepo va nous aider à partager la logique métier entre nos différentes applications. Nous avons également bien délimité le périmètre et les fonctionnalités attendues pour notre première version, le MVP, de broney.

Enfin, à la fin de cet article nous avons commencé à entrevoir la structure du projet en mettant en évidence l'Architecture Hexagonale, ce sera le thème de la deuxième partie : Développer sans UI avec l'Architecture Hexagonale.

Échangeons sur votre projet !

Développement web
Application mobile
Data & IA
Nous contacter

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

Renseignez votre adresse mail pour recevoir l’estimation !
Obtenez l’estimation
Précédent
Suivant

Bravo ! Vous avez terminé
l’estimation de votre future app !

Vous recevrez dans votre boite mail l’estimation personnalisé. Une estimation vous offre la possibilité de vous projeter dans un budget, vous permettant ainsi de planifier en toute confiance. Néanmoins, chez Yield, nous adoptons une approche agile, prêts à remettre en question et ajuster nos évaluations en fonction de l'évolution de vos besoins et des spécificités de votre projet.
Retour au site
Oops! Something went wrong while submitting the form.