De zéro à la build : guide étape par étape

Installation et configuration de Lino CLI

La première étape pour commencer à travailler avec Lino CLI est d’installer l’outil dans votre environnement de développement. Il est distribué en tant que outil global dotnet, ce qui signifie qu’il sera disponible pour tout projet .NET sur votre ordinateur.

Étape 1 : Installation

Pour installer (ou mettre à jour) Lino CLI, exécutez la commande suivante dans le terminal :

dotnet tool install --global Tolitech.Lino

Remarques importantes :

• Si une version est déjà installée, vous pouvez utiliser dotnet tool update --global Tolitech.Lino pour la mettre à jour.
• Assurez-vous que le répertoire des outils globaux .NET est dans le PATH système afin que la commande lino fonctionne correctement.

Étape 2 : Configurer la langue

Après l’installation, il est recommandé de configurer la langue (ou culture) que le CLI utilisera pour les messages, les invites et les logs :

lino preferences culture set

Vous serez invité à choisir parmi les langues disponibles. Cette configuration garantit que toutes les instructions et invites apparaissent de manière cohérente dans la langue souhaitée.

Étape 3 : Authentification et inscription

Pour accéder à toutes les fonctionnalités de Lino, y compris les templates avancés, la publication d’images Docker et l’intégration avec des services externes, l’authentification est requise.

- Si vous n’avez pas encore de compte, inscrivez-vous avec la commande :

lino user register

- Si vous avez déjà un compte, connectez-vous avec :

lino auth login

Ce qui se passe : le CLI stocke un jeton d’authentification localement, vous permettant d’exécuter des commandes nécessitant l’accès à des ressources protégées sans devoir vous connecter à chaque utilisation.

Étape 4 : Vérification

Pour confirmer que l’installation et l’authentification ont été effectuées avec succès, exécutez :

lino --version

Si la commande renvoie la version installée, vous êtes prêt à commencer à utiliser Lino CLI dans vos projets.

Création du projet MyApp

Dans cette étape, nous allons créer la structure initiale du projet en utilisant Lino CLI. Ce projet servira de base pour démontrer la création de services, modules, front-end et l’intégration des événements.

Étape 1 : Exécution de la commande de création

Pour créer un nouveau projet, exécutez la commande suivante dans le terminal :

lino project new

Le CLI vous guidera étape par étape en demandant des informations telles que :

• Nom du projet : nous utiliserons MyApp, mais vous pouvez choisir n’importe quel nom ;
• Fonctionnalités supplémentaires : analyseurs de code, cache distribué, support des événements asynchrones, etc.

Étape 2 : Configuration des fonctionnalités essentielles

Pour ce projet, nous recommandons d’activer dès le départ les fonctionnalités suivantes :

• Analyseurs de code : pour s’assurer que le code respecte les bonnes pratiques et des standards cohérents, en évitant les erreurs courantes d’implémentation ;
• Cache distribué : améliore les performances de l’application dans des scénarios multi-services, en évitant les requêtes inutiles à la base de données ;
• Communication asynchrone : permet l’utilisation d’événements et de files d’attente pour l’intégration entre services, garantissant scalabilité et découplage.

Il est important d’activer toutes ces options dans ce projet, car nous allons créer plusieurs services qui communiqueront via des événements d’intégration. Cela vous permettra de comprendre comment structurer des systèmes modulaires et distribués avec Lino.

Étape 3 : Structure générée

Après l’exécution de la commande et la configuration des fonctionnalités, le CLI générera la structure initiale du projet. Elle inclura :

• Dossiers pour les services et modules ;
• Templates pour le front-end (si applicable) ;
• Configurations initiales pour le cache, les événements et l’intégration ;
• Fichiers de solution (.slnx) et de projet (.csproj) prêts à être compilés.

Votre projet MyApp est maintenant prêt à recevoir les services, modules, entités et front-end que nous configurerons dans les étapes suivantes.

Ajout du frontend

Nous allons maintenant créer l’interface du système, le frontend, qui sera utilisé comme Backoffice. Ce frontend ne sera pas une application publique, mais un outil interne permettant aux administrateurs et aux gestionnaires de gérer les produits, les catégories, les stocks, les ventes et d’autres informations du système.

Étape 1 : Exécution de la commande de création

Pour ajouter un nouveau frontend au projet, utilisez la commande suivante dans le terminal :

lino webapp new

Le CLI demandera certaines informations pendant le processus, telles que :

• Nom de l’application web : nous utiliserons Backoffice pour cet exemple ;

Étape 2 : Structure générée

À la fin du processus, le CLI générera la structure initiale du frontend dans le dossier WebApps/Backoffice. La structure par défaut comprend :

• Dossiers pour les pages, composants et services de l’application ;
• Clients HTTP pour consommer les API des services du projet ;
• Modèles initiaux ;
• Fichiers de configuration pour l’intégration avec l’authentification, l’autorisation et les événements du système.

Remarques importantes

• Le frontend sera automatiquement intégré aux services et modules sélectionnés, permettant de consommer directement les données de produits, de catégories et de ventes via les API générées par Lino.
• Vous pouvez créer plusieurs frontends, par exemple un pour les administrateurs (Backoffice) et un autre public (Site), en suivant le même processus.

Avec le frontend créé, nous sommes prêts à passer à la création des services et des modules qui fourniront les données et les règles métier pour cette application.

Création de services et de modules

À cette étape, nous allons construire les services et modules qui composeront l'application. L'objectif est de créer une architecture modulaire et évolutive, permettant aux différentes parties du système, telles que les produits, catégories, stocks, ventes et médias, d'évoluer de manière indépendante, tout en maintenant la cohésion et en facilitant la maintenance.

Étape 1 : Définition des services

Tout d'abord, nous allons créer les services suivants, chacun avec des responsabilités clairement définies :

• Catalog (modulaire) – responsable de la gestion des produits, catégories et prix ;
• Sales – responsable du traitement des ventes et des commandes ;
• Stock – responsable de la gestion des stocks et des mouvements ;
• Security – responsable de l'authentification, de l'autorisation et de la gestion des utilisateurs.

Pour créer un nouveau service, exécutez la commande :

lino service new

Lors de l'exécution de la commande, le CLI demandera :

• Nom du service : par exemple, Catalog ;
• Base de données : choisissez la technologie la plus adaptée à votre projet (SQL Server, PostgreSQL, etc.) ;

Étape 2 : Création de modules au sein des services

Tous les services n'ont pas besoin d'être modulaires. Dans notre projet, seul le service Catalog aura des modules, afin de séparer des responsabilités telles que le merchandising et la tarification.

Pour le service Catalog, nous avons défini les modules suivants :

• Merchandising – gestion des produits et des catégories ;
• Pricing – gestion des prix, promotions et historique des modifications.

Pour créer un module, exécutez la commande :

lino module new

Vous pouvez créer autant de modules que vous le souhaitez dans le service modulaire Catalog. De plus, selon la complexité, certains modules pourraient devenir des services indépendants à l'avenir. La séparation présentée ici est uniquement à des fins pédagogiques et sert d'exemple d'organisation modulaire.

Structure finale du projet

Après avoir créé les services et les modules, votre solution devrait avoir une structure similaire à la suivante :

MyApp/
└── src/
    ├── Aspire/
    ├── Integrations/
    ├── Services/
    │   ├── Catalog/
    │   │   ├── Modules/
    │   │   │   ├── Merchandising/
    │   │   │   └── Pricing/
    │   │   ├── MyApp.Catalog.Host
    │   │   └── MyApp.Catalog.Infrastructure
    │   ├── Sales/
    │   ├── Security/
    │   ├── Shared/
    │   └── Stock/
    └── WebApps/
        ├── Backoffice/
        │   ├── Services/
        │   │   ├── Catalog/
        │   │   ├── Sales/
        │   │   ├── Security/
        │   │   └── Stock/
        │   ├── MyApp.WebApp.Backoffice
        │   └── MyApp.WebApp.Backoffice.Client
        └── Shared/
            └── MyApp.WebApp.Shared
└── tests/
    └── Services/
        ├── Catalog/
        │   ├── Merchandising/
        │   └── Pricing/
        ├── Sales/
        ├── Security/
        ├── Shared/
        └── Stock/

Explication de la structure :

• Services/ : contient tous les services du système, chacun isolé avec sa propre logique métier, infrastructure et hébergement ;
• Modules/ : dossiers au sein des services modulaires, permettant d'organiser des fonctionnalités spécifiques et de maintenir un code cohérent ;
• WebApps/ : frontends associés au système, déjà intégrés aux services ;
• Shared/ : bibliothèques et ressources partagées entre services et frontends ;
• tests/ : tests unitaires et d'intégration organisés par service et module.

Avec cette structure modulaire, chaque équipe ou développeur peut travailler de manière indépendante sur différentes parties du système, facilitant l'évolutivité, la maintenance et les tests.

Ajout de l’authentification et de l’autorisation

L’authentification et l’autorisation sont des éléments essentiels de tout système moderne. Dans Lino CLI, les ajouter à votre projet est simple et rapide.

Étape 1 : Exécution de la commande d’authentification

Pour ajouter les fonctionnalités d’authentification et d’autorisation, utilisez la commande :

lino features auth add

Le CLI vous guidera à travers les étapes suivantes :

• Choix du service ou du module : vous devez indiquer où les artefacts d’authentification seront installés. Dans notre projet exemple, nous utilisons le service Security, qui centralise toute la logique de sécurité du système ;
• Configurations supplémentaires : création des tables pour les utilisateurs, rôles et permissions, et configuration des politiques d’accès.

Étape 2 : Structure générée

Après l’exécution de la commande, le service Security contiendra des fichiers et dossiers tels que :

• Entities : classes pour les utilisateurs, rôles et permissions ;
• Infrastructure : configurations de la base de données et migrations pour créer les tables ;
• Application : services d’authentification, gestion des utilisateurs et validation des identifiants ;
• API/Host : endpoints pour la connexion, la déconnexion, l’inscription et la gestion des rôles.

Avec cette configuration, votre application disposera d’une authentification robuste et d’un contrôle d’accès granulaire, prête à supporter plusieurs utilisateurs et différents niveaux de permissions.

Ajout de Background Jobs

Dans les systèmes distribués et modulaires, comme celui que nous construisons avec le Lino CLI, tous les services ne communiquent pas directement entre eux. Pour garantir la cohérence et la fiabilité de l’échange d’informations, nous utilisons des événements d’intégration. Cependant, pour traiter ces événements de manière efficace et asynchrone, nous avons besoin de Background Jobs.

Lino utilise le Outbox Pattern pour s’assurer que tous les messages générés par les services sont enregistrés de manière fiable avant d’être envoyés. Cela nous permet de :

• Éviter la perte d’événements en cas de défaillance ou de redémarrage du service ;
• Garantir qu’un même message ne soit envoyé qu’une seule fois ;
• Permettre le retraitement des messages en cas d’échec de livraison ;
• Séparer le traitement des événements de la logique principale de l’application, améliorant les performances et la scalabilité.

Étape 1 : Exécution de la commande

Pour ajouter la prise en charge des Background Jobs à votre projet, exécutez la commande :

lino features background-job add

Le CLI vous demandera de sélectionner le service dans lequel le Background Job sera installé. En général, vous choisirez le service qui centralise la production des événements, comme Catalog ou Sales.

Étape 2 : Configuration de l’exécution

Pendant la configuration, vous pouvez définir :

• Intervalle de vérification : détermine la fréquence à laquelle le Background Job vérifiera la table Outbox pour de nouveaux messages. Un intervalle trop court peut augmenter l’utilisation des ressources, tandis qu’un intervalle trop long peut retarder la livraison des événements ;
• Taille du lot de messages traités par exécution : contrôle le nombre d’événements lus et envoyés à chaque exécution. Des lots plus importants peuvent améliorer les performances mais nécessitent plus de mémoire et de puissance de traitement ;
• Politique de réessai : en cas d’échec de l’envoi des messages, vous pouvez configurer le nombre de tentatives de renvoi du job.

Ces paramètres dépendent de la taille de votre système, des capacités de la machine et du volume d’événements attendu.

Étape 3 : Structure générée

Après configuration, le projet disposera d’un Background Job prêt à traiter les messages des tables Outbox dans chaque service.

Cela garantit que tous les événements d’intégration sont traités de manière fiable et efficace, permettant à plusieurs services et modules de communiquer de façon asynchrone sans impacter les performances du système principal.

Création d'entités et d'énumérations

Dans cette section, nous détaillons la conception des entités, des énumérations et des objets de valeur de l'application, en montrant dans quels services et modules chaque élément sera créé.

1. Création de l'entité Category

Pour créer l'entité, utilisez la commande :

lino entity new

L'entité sera créée dans le service Catalog et dans le module Merchandising avec la structure suivante :

┌────┬────┬───────────────┬────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type   │ Length │ Required │ Auto-increment │
├────┼────┼───────────────┼────────┼────────┼──────────┼────────────────┤
│ x  │    │ Id            │ Guid   │        │    x     │       x        │
├────┼────┼───────────────┼────────┼────────┼──────────┼────────────────┤
│    │    │ Name          │ string │   50   │    x     │                │
└────┴────┴───────────────┴────────┴────────┴──────────┴────────────────┘

2. Création de l'entité Product

Ensuite, nous créons l'entité Product dans le même service et module, en incluant les objets de valeur et les énumérations :

┌────┬────┬───────────────┬─────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type        │ Length │ Required │ Auto-increment │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│ x  │    │ Id            │ Guid        │        │    x     │       x        │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │    │ Name          │ string      │  100   │    x     │                │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │    │ Description   │ string      │  500   │    x     │                │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │    │ Price         │ decimal     │        │    x     │                │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │ x  │ CategoryId    │ Category    │        │    x     │                │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │    │ Dimensions    │ ValueObject │        │          │                │
├────┼────┼───────────────┼─────────────┼────────┼──────────┼────────────────┤
│    │    │ Status        │ Enum        │        │    x     │                │
└────┴────┴───────────────┴─────────────┴────────┴──────────┴────────────────┘

2.1 Création de l'objet de valeur ProductDimension

Cet objet de valeur représente les dimensions du produit :

┌───────────────┬─────────┬────────┬──────────┐
│ Property name │ Type    │ Length │ Required │
├───────────────┼─────────┼────────┼──────────┤
│ Width         │ decimal │        │    x     │
├───────────────┼─────────┼────────┼──────────┤
│ Height        │ decimal │        │    x     │
├───────────────┼─────────┼────────┼──────────┤
│ Depth         │ decimal │        │    x     │
└───────────────┴─────────┴────────┴──────────┘

2.2 Création de l'Enum ProductStatus

Cet Enum définit le statut du produit :

┌───────┬──────────────┬──────────────┐
│ Value │ Name         │ Display Name │
├───────┼──────────────┼──────────────┤
│ 1     │ Active       │ Active       │
├───────┼──────────────┼──────────────┤
│ 2     │ Inactive     │ Inactive     │
├───────┼──────────────┼──────────────┤
│ 3     │ Discontinued │ Discontinued │
└───────┴──────────────┴──────────────┘

3. Ajout de nouvelles propriétés

Avec l'évolution du projet, nous pouvons modifier les entités existantes pour ajouter de nouvelles propriétés. Par exemple, nous ajouterons une liste d'images à l'entité Product :

lino entity edit

En créant la propriété Images de type List<ProductImage>, nous obtenons la structure suivante :

┌────┬────┬───────────────┬────────────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type               │ Length │ Required │ Auto-increment │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│ x  │    │ Id            │ Guid               │        │    x     │       x        │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │    │ Name          │ string             │  100   │    x     │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │    │ Description   │ string             │  500   │    x     │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │    │ Price         │ decimal            │        │    x     │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │ x  │ CategoryId    │ EntityId           │        │    x     │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │    │ Dimensions    │ ValueObject        │        │          │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │    │ Status        │ Enum               │        │    x     │                │
├────┼────┼───────────────┼────────────────────┼────────┼──────────┼────────────────┤
│    │ x  │ Images        │ List<ProductImage> │        │          │                │
└────┴────┴───────────────┴────────────────────┴────────┴──────────┴────────────────┘

3.1 Création de l'entité ProductImage

Cette entité appartient à l'agrégat Product et a la structure suivante :

┌────┬────┬───────────────┬────────────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type           │ Length │ Required │ Auto-increment │
├────┼────┼───────────────┼────────────────┼────────┼──────────┼────────────────┤
│ x  │    │ Id            │ Guid           │        │    x     │       x        │
├────┼────┼───────────────┼────────────────┼────────┼──────────┼────────────────┤
│    │ x  │ ProductId     │ EntityId       │        │    x     │                │
├────┼────┼───────────────┼────────────────┼────────┼──────────┼────────────────┤
│    │    │ UploadDate    │ DateTimeOffset │        │    x     │                │
├────┼────┼───────────────┼────────────────┼────────┼──────────┼────────────────┤
│    │    │ Image         │ File           │        │    x     │                │
└────┴────┴───────────────┴────────────────┴────────┴──────────┴────────────────┘

4. Création d'entités pour d'autres services

Dans le service Sales, nous créons l'entité ProductSnapshot, qui sera alimentée par les événements d'intégration. Comme l'Id original de l'entité Product provient du service Catalog, il ne peut pas être auto-incrémenté ici.

┌────┬────┬───────────────┬─────────┬────────┬──────────┬────────────────┐
│ PK │ FK │ Property name │ Type    │ Length │ Required │ Auto-increment │
├────┼────┼───────────────┼─────────┼────────┼──────────┼────────────────┤
│ x  │    │ Id            │ Guid    │        │    x     │                │
├────┼────┼───────────────┼─────────┼────────┼──────────┼────────────────┤
│    │    │ Name          │ string  │  100   │    x     │                │
├────┼────┼───────────────┼─────────┼────────┼──────────┼────────────────┤
│    │    │ Price         │ decimal │        │    x     │                │
└────┴────┴───────────────┴─────────┴────────┴──────────┴────────────────┘

Remarque : seuls les champs essentiels ont été répliqués dans ProductSnapshot pour le service Sales. Les entités supplémentaires, telles que Customer, Order et StockItem, ne seront pas détaillées ici pour simplifier la documentation.

Création d'événements et de leurs gestionnaires

Pour récapituler, dans la section précédente, nous avons créé dans le service modulaire Catalog.Merchandising les entités Product, Category et ProductImage, tandis que dans le service Sales, nous avons créé l'entité ProductSnapshot.

Nous allons maintenant créer des événements de domaine et des événements d'intégration. L'objectif est que, lorsqu'un produit est créé ou mis à jour dans le service Catalog, ces modifications soient répliquées vers les services consommateurs tels que Sales et Stock.

1. Création des événements de domaine

La première étape consiste à créer les événements de domaine ProductCreated et ProductUpdated avec la commande :

lino event new

Lors de la création, vous pouvez associer l'événement à un gestionnaire et configurer simultanément le déclenchement d'un événement d'intégration. Cela centralise la création de tout le flux nécessaire.

┌──────────────────────────────────────────────────────┬────────────────────────────────┐
│ Question                                             │ Answer                         │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a service:                                    │ Catalog                        │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a module:                                     │ Merchandising                  │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a entity:                                     │ Product                        │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select the event type:                               │ Domain Event                   │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Enter the name of the event:                         │ ProductCreated                 │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Do you want to create an associated event handler?   │ Yes                            │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Trigger a integration event?                         │ Yes                            │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Choose the integration event to be triggered:        │ (Create new integration event) │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Enter the name of the event:                         │ ProductCreated                 │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Which model will be used for this integration event? │ Creation model                 │
└──────────────────────────────────────────────────────┴────────────────────────────────┘

De la même manière, nous créons l'événement ProductUpdated :

┌──────────────────────────────────────────────────────┬────────────────────────────────┐
│ Question                                             │ Answer                         │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a service:                                    │ Catalog                        │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a module:                                     │ Merchandising                  │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select a entity:                                     │ Product                        │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Select the event type:                               │ Domain Event                   │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Enter the name of the event:                         │ ProductUpdated                 │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Do you want to create an associated event handler?   │ Yes                            │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Trigger a integration event?                         │ Yes                            │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Choose the integration event to be triggered:        │ (Create new integration event) │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Enter the name of the event:                         │ ProductUpdated                 │
├──────────────────────────────────────────────────────┼────────────────────────────────┤
│ Which model will be used for this integration event? │ Update model                   │
└──────────────────────────────────────────────────────┴────────────────────────────────┘

Ainsi, nous avons :

• Événements de domaine créés (ProductCreated et ProductUpdated)
• Gestionnaires d'événements de domaine correspondants
• Événements d'intégration automatiquement enregistrés dans l'Outbox par le gestionnaire d'événements de domaine

2. Création des gestionnaires d'événements d'intégration

L'étape suivante consiste à définir quels services consommeront les événements d'intégration. Pour cela, nous utilisons :

lino event-handler new

Le flux de création inclut :

• La sélection du service, du module et de l'entité qui contiendra le gestionnaire
• La sélection de l'événement d'intégration à consommer et de son service/module/entité d'origine

Par exemple, dans le service Sales, nous créons les gestionnaires pour ProductCreated et ProductUpdated qui consommeront les événements émis par Catalog.Merchandising.Product :

┌────────────────────────────────────────────┬───────────────────┐
│ Question                                   │ Answer            │
├────────────────────────────────────────────┼───────────────────┤
│ Select a service:                          │ Sales             │
├────────────────────────────────────────────┼───────────────────┤
│ Select a entity:                           │ ProductSnapshot   │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event type:                     │ Integration Event │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's service to be consumed: │ Catalog           │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's module to be consumed:  │ Merchandising     │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's entity to be consumed:  │ Product           │
├────────────────────────────────────────────┼───────────────────┤
│ Choose the event to be consumed:           │ ProductCreated    │
├────────────────────────────────────────────┼───────────────────┤
│ Enter the name of the event handler:       │ ProductCreated    │
└────────────────────────────────────────────┴───────────────────┘

┌────────────────────────────────────────────┬───────────────────┐
│ Question                                   │ Answer            │
├────────────────────────────────────────────┼───────────────────┤
│ Select a service:                          │ Sales             │
├────────────────────────────────────────────┼───────────────────┤
│ Select a entity:                           │ ProductSnapshot   │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event type:                     │ Integration Event │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's service to be consumed: │ Catalog           │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's module to be consumed:  │ Merchandising     │
├────────────────────────────────────────────┼───────────────────┤
│ Select the event's entity to be consumed:  │ Product           │
├────────────────────────────────────────────┼───────────────────┤
│ Choose the event to be consumed:           │ ProductUpdated    │
├────────────────────────────────────────────┼───────────────────┤
│ Enter the name of the event handler:       │ ProductUpdated    │
└────────────────────────────────────────────┴───────────────────┘

Ainsi, nous avons deux gestionnaires d'événements d'intégration dans le service Sales, consommant uniquement les champs nécessaires des événements d'intégration de Catalog.Merchandising. Cela garantit que les tables répliquées ne contiennent que les données essentielles, optimisant ainsi le stockage et les performances.

Génération de pages web, API, Commands et Queries

L’un des grands avantages de Lino CLI est de permettre la création intégrée de pages web, API, Commands et Queries de manière automatisée, simplifiant ainsi l’ensemble du flux de développement. Pour commencer, il suffit d’exécuter la commande :

lino page new

Au cours du processus, vous allez :

• Choisir le service, le module et l’entité que vous souhaitez exposer ;
• Choisir les champs qui feront partie de la liste ;
• Générer automatiquement les pages de liste (grille paginée) et les formulaires de création/édition ;
• Générer les classes HttpClient pour la consommation côté frontend ;
• Créer toutes les API REST nécessaires (POST, PUT, PATCH, DELETE et GET) ;
• Créer les Commands et Queries avec leurs Handlers respectifs, qui interagissent avec la base de données pour garantir un flux complet de CRUD.

Avec cette commande, vous obtenez une application fonctionnelle sans avoir à écrire manuellement la couche d’interface, les API et la logique métier, tout en maintenant la norme et la cohérence entre les services.

Pour ce projet, nous pouvons générer les pages intégrées pour les entités suivantes :

• Catalog.Merchandising.Category
• Catalog.Merchandising.Product
• Sales.ProductSnapshot

Après avoir généré les pages, API et Commands/Queries, l’application sera prête à interagir pleinement entre frontend et backend, avec les validations, les routes et la persistance déjà configurées automatiquement par Lino CLI.

Création des migrations de base de données

Maintenant que toutes les entités ont été créées, il est temps de générer les migrations afin que les bases de données soient créées ou mises à jour conformément au modèle défini. Lino CLI automatise ce processus, s’intégrant à Entity Framework et créant des scripts prêts à l’exécution.

Pour créer une nouvelle migration, exécutez la commande :

lino database migrations new

Lors de l’exécution, vous devrez :

• Sélectionner le service et le module qui recevront la migration ;
• Fournir une description pour la migration, par exemple "Initial migration".

┌───────────────────────────────────────────┬───────────────────┐
│ Question                                  │ Answer            │
├───────────────────────────────────────────┼───────────────────┤
│ Select a service:                         │ Catalog           │
├───────────────────────────────────────────┼───────────────────┤
│ Select a module:                          │ Merchandising     │
├───────────────────────────────────────────┼───────────────────┤
│ Current version of the service:           │ 0.1.0             │
├───────────────────────────────────────────┼───────────────────┤
│ Provide a description for this migration: │ Initial migration │
└───────────────────────────────────────────┴───────────────────┘

Après confirmation, Lino CLI générera :

• Une nouvelle migration de base de données pour la version actuelle du service ;
• Un script SQL correspondant, situé dans la couche Infrastructure.Persistence, à l’emplacement /scripts/<version>/<nom du fichier> ;
• L’enregistrement de la version de la migration dans l’historique du service, garantissant traçabilité et cohérence.

Bonnes pratiques :

• Créer de nouvelles migrations à chaque modification du modèle de données (nouvelles entités, propriétés ou changements de relations) ;
• Vérifier les scripts SQL générés avant de les appliquer en production ;
• Maintenir le contrôle des versions de la base de données aligné avec la version de l’application afin d’éviter les conflits et les problèmes de synchronisation.

En suivant ce flux, vous vous assurez que la base de données est toujours à jour et cohérente avec le modèle de domaine défini dans Lino CLI, réduisant ainsi les erreurs et simplifiant la maintenance.

Génération d’images Docker

Après avoir terminé la génération du code pour une version spécifique, effectué les tests et implémenté toutes les règles métier nécessaires, vous pouvez générer des images Docker pour les services et applications web de votre projet afin de les publier ensuite dans un registre de conteneurs.

Lino CLI simplifie ce processus avec la commande :

lino build

Lors de l’exécution, vous verrez la liste de tous les services et applications web disponibles dans le projet, ainsi que leurs versions actuelles :

Select the services or web applications you want to include in the build:

> [ ] Services
    [ ] Catalog |0.1.0|
    [ ] Sales |0.1.0|
    [ ] Security |0.1.0|
    [ ] Stock |0.1.0|
  [ ] Web applications
    [ ] Backoffice |0.1.0|

Vous pouvez sélectionner un ou plusieurs services et applications web pour générer les images simultanément. Il suffit de cocher les éléments souhaités.

Ensuite, il vous sera demandé de choisir comment mettre à jour la version des images générées. Les options disponibles sont :

• Conserver la version actuelle – ne modifie pas la version existante ;
• Patch – incrémente la version patch (ex. : 0.1.0 → 0.1.1) ;
• Minor – incrémente la version mineure (ex. : 0.1.0 → 0.2.0) ;
• Major – incrémente la version majeure (ex. : 0.1.0 → 1.0.0) ;

Après avoir sélectionné les services et défini l’incrément de version, Lino CLI effectue :

• Build du code de chaque service et application web ;
• Génération de l’image Docker correspondante ;
• Application du tag avec la version définie ;
• Mise à disposition des images pour publication dans votre registre de conteneurs.

À la fin du processus, si tous les services et applications web ont été sélectionnés, les images générées auront la structure suivante :

• my-app/services/catalog-host - tag: 0.1.0
• my-app/services/sales-api - tag: 0.1.0
• my-app/services/security-api - tag: 0.1.0
• my-app/services/stock-api - tag: 0.1.0
• my-app/webapps/backoffice - tag: 0.1.0

Remarque : Ce processus garantit la cohérence entre le code et la version des images Docker, facilitant le déploiement et la maintenance de plusieurs environnements, tout en permettant à chaque service d’être isolé dans des conteneurs indépendants.

Création de versions dans l’application

L’incrémentation de nouvelles versions pour les services ou applications web est un processus simple et centralisé dans Lino CLI. Il suffit d’exécuter la commande :

lino version bump

Comme pour la génération d’images Docker, l’exécution de cette commande affichera la liste complète de tous les services et applications web de votre projet. Seuls les éléments sélectionnés verront leur version incrémentée, les autres resteront inchangés.

Select the services or web applications that will have version changes:

> [ ] Services
    [ ] Catalog |0.1.0|
    [ ] Sales |0.1.0|
    [ ] Security |0.1.0|
    [ ] Stock |0.1.0|
  [ ] Web applications
    [ ] Backoffice |0.1.0|

Après avoir sélectionné les éléments souhaités, il vous sera demandé de choisir le type d’incrément de version. Les options disponibles sont :

• Patch – petites corrections sans impact fonctionnel ;
• Minor – ajout de nouvelles fonctionnalités compatibles avec les versions précédentes ;
• Major – modifications pouvant casser la compatibilité avec les versions précédentes.

Il est important de noter que les versions des services et applications web ont un impact direct sur :

• Les tags des images Docker ;
• Les dossiers utilisés pour stocker les scripts générés par les migrations de base de données ;
• Le contrôle des releases et l’historique du projet.

Ainsi, nous concluons le guide étape par étape de toutes les commandes essentielles pour la création d’un projet web avec Lino CLI, de l’installation, création de services, entités, événements et pages, jusqu’à la génération d’images Docker et la gestion des versions.

N’oubliez pas de suivre notre chaîne YouTube pour des tutoriels détaillés, des démonstrations pratiques et des conseils d’utilisation de l’outil, des opérations simples aux fonctionnalités avancées.