Von null bis Build: Schritt-für-Schritt-Anleitung

Installation und Konfiguration von Lino CLI

Der erste Schritt, um mit Lino CLI zu arbeiten, besteht darin, das Tool in Ihrer Entwicklungsumgebung zu installieren. Es wird als dotnet Global Tool bereitgestellt, was bedeutet, dass es für jedes .NET-Projekt auf Ihrem Computer verfügbar ist.

Schritt 1: Installation

Um Lino CLI zu installieren (oder zu aktualisieren), führen Sie den folgenden Befehl im Terminal aus:

dotnet tool install --global Tolitech.Lino

Wichtige Hinweise:

• Wenn bereits eine Version installiert ist, können Sie dotnet tool update --global Tolitech.Lino verwenden, um sie zu aktualisieren.
• Stellen Sie sicher, dass das Verzeichnis für globale .NET-Tools im System-PATH enthalten ist, damit der Befehl lino korrekt funktioniert.

Schritt 2: Sprache einstellen

Nach der Installation wird empfohlen, die Sprache (oder Kultur) zu konfigurieren, die das CLI für Nachrichten, Eingabeaufforderungen und Logs verwenden soll:

lino preferences culture set

Sie werden aufgefordert, eine der verfügbaren Sprachen auszuwählen. Diese Einstellung stellt sicher, dass alle Anweisungen und Aufforderungen konsistent in der gewünschten Sprache angezeigt werden.

Schritt 3: Authentifizierung und Registrierung

Um auf alle Funktionen von Lino zuzugreifen, einschließlich erweiterter Vorlagen, Docker-Image-Publikationen und Integration mit externen Diensten, ist eine Authentifizierung erforderlich.

- Falls Sie noch kein Konto haben, registrieren Sie sich mit folgendem Befehl:

lino user register

- Falls Sie bereits ein Konto haben, melden Sie sich mit folgendem Befehl an:

lino auth login

Was passiert: Das CLI speichert ein Authentifizierungstoken lokal, sodass Sie Befehle ausführen können, die Zugriff auf geschützte Ressourcen erfordern, ohne sich jedes Mal anmelden zu müssen.

Schritt 4: Überprüfung

Um zu bestätigen, dass Installation und Authentifizierung erfolgreich waren, führen Sie aus:

lino --version

Wenn der Befehl die installierte Version zurückgibt, sind Sie bereit, Lino CLI in Ihren Projekten zu verwenden.

Erstellen des Projekts MyApp

In diesem Schritt erstellen wir die anfängliche Projektstruktur mithilfe von Lino CLI. Dieses Projekt dient als Basis, um die Erstellung von Services, Modulen, Front-End und die Integration von Events zu demonstrieren.

Schritt 1: Ausführen des Erstellungsbefehls

Um ein neues Projekt zu erstellen, führen Sie den folgenden Befehl im Terminal aus:

lino project new

Das CLI führt Sie Schritt für Schritt und fragt dabei nach Informationen wie:

• Projektname: wir verwenden MyApp, Sie können jedoch jeden beliebigen Namen wählen;
• Zusätzliche Funktionen: Code-Analysetools, verteiltes Caching, Unterstützung für asynchrone Events usw.

Schritt 2: Konfigurieren der Kernfunktionen

Für dieses Projekt empfehlen wir, die folgenden Funktionen von Anfang an zu aktivieren:

• Code-Analysetools: stellen sicher, dass der Code Best Practices und konsistente Standards einhält und häufige Implementierungsfehler verhindert;
• Verteiltes Caching: verbessert die Anwendungsleistung in Multi-Service-Szenarien und verhindert unnötige Datenbankabfragen;
• Asynchrone Kommunikation: ermöglicht die Nutzung von Events und Queues für die Integration zwischen Services und gewährleistet Skalierbarkeit und Entkopplung.

Es ist wichtig, alle diese Optionen in diesem Projekt zu aktivieren, da wir mehrere Services erstellen werden, die über Integrations-Events kommunizieren. Dies ermöglicht es Ihnen, zu verstehen, wie modulare und verteilte Systeme mit Lino strukturiert werden.

Schritt 3: Generierte Struktur

Nach Ausführung des Befehls und Konfiguration der Funktionen generiert das CLI die anfängliche Projektstruktur. Diese umfasst:

• Ordner für Services und Module;
• Templates für Front-End (falls zutreffend);
• Anfangskonfigurationen für Cache, Events und Integrationen;
• Lösungsdateien (.slnx) und Projektdateien (.csproj), bereit zur Kompilierung.

Ihr Projekt MyApp ist nun bereit, die Services, Module, Entitäten und das Front-End zu erhalten, die wir in den nächsten Schritten konfigurieren werden.

Hinzufügen des Frontends

Nun erstellen wir die Systemoberfläche, das Frontend, das als Backoffice verwendet wird. Dieses Frontend wird keine öffentliche Anwendung sein, sondern ein internes Tool, mit dem Administratoren und Manager Produkte, Kategorien, Bestände, Verkäufe und andere Systeminformationen verwalten können.

Schritt 1: Ausführen des Erstellungskommandos

Um dem Projekt ein neues Frontend hinzuzufügen, verwenden Sie den folgenden Befehl im Terminal:

lino webapp new

Die CLI wird während des Prozesses einige Informationen abfragen, wie zum Beispiel:

• Name der Webanwendung: für dieses Beispiel verwenden wir Backoffice;

Schritt 2: Generierte Struktur

Am Ende des Prozesses erstellt die CLI die anfängliche Frontend-Struktur im Ordner WebApps/Backoffice. Die Standardstruktur umfasst:

• Ordner für Seiten, Komponenten und Dienste der Anwendung;
• HTTP-Clients zum Konsumieren von APIs der Projektdienste;
• Startvorlagen;
• Konfigurationsdateien für die Integration mit Authentifizierung, Autorisierung und Systemereignissen.

Wichtige Hinweise

• Das Frontend wird automatisch mit den ausgewählten Diensten und Modulen integriert, sodass Produkt-, Kategorien- und Verkaufsdaten direkt über die von Lino generierten APIs konsumiert werden können.
• Sie können mehrere Frontends erstellen, zum Beispiel eines für Administratoren (Backoffice) und ein weiteres öffentliches (Site), indem Sie denselben Prozess befolgen.

Mit dem erstellten Frontend sind wir bereit, mit der Erstellung der Dienste und Module fortzufahren, die die Daten und Geschäftsregeln für diese Anwendung bereitstellen werden.

Erstellen von Services und Modulen

In diesem Schritt werden wir die Services und Module erstellen, die die Anwendung bilden. Ziel ist es, eine modulare und skalierbare Architektur zu schaffen, die es verschiedenen Bereichen des Systems, wie Produkte, Kategorien, Lager, Vertrieb und Medien, ermöglicht, sich unabhängig weiterzuentwickeln, während Kohäsion erhalten und Wartung erleichtert wird.

Schritt 1: Definition der Services

Zunächst erstellen wir die folgenden Services, jeder mit klar definierten Verantwortlichkeiten:

• Catalog (modular) – verantwortlich für die Verwaltung von Produkten, Kategorien und Preisen;
• Sales – verantwortlich für die Verarbeitung von Verkäufen und Bestellungen;
• Stock – verantwortlich für die Verwaltung von Lagerbeständen und Bewegungen;
• Security – verantwortlich für Authentifizierung, Autorisierung und Benutzerverwaltung.

Um einen neuen Service zu erstellen, führen Sie folgenden Befehl aus:

lino service new

Während der Ausführung des Befehls fragt das CLI:

• Service-Name: z.B. Catalog;
• Datenbank: wählen Sie die Technologie, die am besten zu Ihrem Projekt passt (SQL Server, PostgreSQL, etc.);

Schritt 2: Erstellen von Modulen innerhalb der Services

Nicht alle Services müssen modular sein. In unserem Projekt hat nur der Service Catalog Module, um Verantwortlichkeiten wie Merchandising und Pricing zu trennen.

Für den Service Catalog haben wir die folgenden Module definiert:

• Merchandising – Verwaltung von Produkten und Kategorien;
• Pricing – Verwaltung von Preisen, Aktionen und Änderungsverläufen.

Um ein Modul zu erstellen, führen Sie folgenden Befehl aus:

lino module new

Sie können beliebig viele Module innerhalb des modularen Services Catalog erstellen. Abhängig von der Komplexität könnten einige Module zukünftig eigenständige Services werden. Die hier gezeigte Aufteilung dient nur zu Schulungszwecken und als Beispiel für modulare Organisation.

Endstruktur des Projekts

Nach der Erstellung der Services und Module sollte Ihre Lösung eine Struktur wie folgt haben:

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/

Erklärung der Struktur:

• Services/: enthält alle Services des Systems, jeder isoliert mit eigener Geschäftslogik, Infrastruktur und Hosting;
• Modules/: Ordner innerhalb der modularen Services, zur Organisation spezifischer Funktionen und zur Wahrung des zusammenhängenden Codes;
• WebApps/: Frontends, die mit dem System verbunden sind und bereits in die Services integriert sind;
• Shared/: Bibliotheken und Ressourcen, die zwischen Services und Frontends geteilt werden;
• tests/: Unit- und Integrationstests, organisiert nach Service und Modul.

Mit dieser modularen Struktur kann jedes Team oder jeder Entwickler unabhängig an verschiedenen Teilen des Systems arbeiten, wodurch Skalierbarkeit, Wartung und Tests erleichtert werden.

Hinzufügen von Authentifizierung und Autorisierung

Authentifizierung und Autorisierung sind wesentliche Elemente jedes modernen Systems. Im Lino CLI ist das Hinzufügen zu Ihrem Projekt einfach und schnell.

Schritt 1: Ausführen des Authentifizierungsbefehls

Um Authentifizierungs- und Autorisierungsfunktionen hinzuzufügen, verwenden Sie den Befehl:

lino features auth add

Das CLI führt Sie durch die folgenden Schritte:

• Auswahl des Dienstes oder Moduls: Sie müssen angeben, wo die Authentifizierungsartefakte installiert werden. In unserem Beispielprojekt verwenden wir den Security-Dienst, der die gesamte Sicherheitslogik des Systems zentralisiert;
• Zusätzliche Konfigurationen: Erstellen von Tabellen für Benutzer, Rollen und Berechtigungen sowie Konfiguration von Zugriffspolicen.

Schritt 2: Generierte Struktur

Nach Ausführung des Befehls enthält der Security-Dienst Dateien und Ordner wie:

• Entities: Klassen für Benutzer, Rollen und Berechtigungen;
• Infrastructure: Datenbankkonfigurationen und Migrationen zum Erstellen der Tabellen;
• Application: Authentifizierungsdienste, Benutzerverwaltung und Validierung von Anmeldeinformationen;
• API/Host: Endpunkte für Login, Logout, Registrierung und Rollenverwaltung.

Mit dieser Einrichtung verfügt Ihre Anwendung über eine robuste Authentifizierung und granulare Zugriffskontrolle, bereit zur Unterstützung mehrerer Benutzer und unterschiedlicher Berechtigungsebenen.

Hinzufügen von Background Jobs

In verteilten und modularen Systemen, wie dem, das wir mit dem Lino CLI erstellen, kommunizieren nicht alle Dienste direkt miteinander. Um Konsistenz und Zuverlässigkeit beim Informationsaustausch zu gewährleisten, verwenden wir Integrationsereignisse. Um diese Ereignisse jedoch effizient und asynchron zu verarbeiten, benötigen wir Background Jobs.

Lino verwendet das Outbox Pattern, um sicherzustellen, dass alle von den Diensten generierten Nachrichten zuverlässig erfasst werden, bevor sie gesendet werden. Damit können wir:

• Verlust von Ereignissen bei Dienstausfällen oder Neustarts vermeiden;
• Garantieren, dass dieselbe Nachricht nur einmal gesendet wird;
• Die erneute Verarbeitung von Nachrichten bei Zustellungsfehlern ermöglichen;
• Die Verarbeitung von Ereignissen von der Hauptlogik der Anwendung trennen, was Leistung und Skalierbarkeit verbessert.

Schritt 1: Ausführen des Befehls

Um Unterstützung für Background Jobs in Ihrem Projekt hinzuzufügen, führen Sie den Befehl aus:

lino features background-job add

Das CLI fordert Sie auf, den Dienst auszuwählen, in dem der Background Job installiert werden soll. In der Regel wählen Sie den Dienst, der die Ereigniserzeugung zentralisiert, z. B. Catalog oder Sales.

Schritt 2: Konfiguration der Ausführung

Während der Konfiguration können Sie Folgendes festlegen:

• Überprüfungsintervall: Bestimmt, wie häufig der Background Job die Outbox-Tabelle auf neue Nachrichten überprüft. Ein zu kurzes Intervall kann die Ressourcennutzung erhöhen, während ein zu langes Intervall die Zustellung der Ereignisse verzögern kann;
• Batchgröße der zu verarbeitenden Einträge: Steuert, wie viele Ereignisse pro Ausführung gelesen und gesendet werden. Größere Batches können die Leistung erhöhen, erfordern jedoch mehr Speicher und Rechenleistung;
• Retry-Politik: Bei einer fehlgeschlagenen Nachrichtenübermittlung können Sie festlegen, wie oft der Job einen erneuten Sendeversuch unternimmt.

Diese Parameter hängen von der Größe Ihres Systems, der Leistungsfähigkeit der Maschine und dem erwarteten Ereignisvolumen ab.

Schritt 3: Generierte Struktur

Nach der Konfiguration verfügt das Projekt über einen Background Job, der Nachrichten aus den Outbox-Tabellen in jedem Dienst verarbeiten kann.

So wird sichergestellt, dass alle Integrationsereignisse zuverlässig und effizient verarbeitet werden, wodurch mehrere Dienste und Module asynchron kommunizieren können, ohne die Leistung des Hauptsystems zu beeinträchtigen.

Erstellen von Entitäten und Enumerationen

In diesem Abschnitt beschreiben wir detailliert das Design der Entitäten, Enumerationen und Value Objects der Anwendung und zeigen, in welchen Services und Modulen jedes Element erstellt wird.

1. Erstellen der Entität Category

Um die Entität zu erstellen, verwenden Sie den Befehl:

lino entity new

Die Entität wird im Service Catalog und im Modul Merchandising mit der folgenden Struktur erstellt:

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

2. Erstellen der Entität Product

Anschließend erstellen wir die Entität Product im gleichen Service und Modul, einschließlich Value Objects und Enumerationen:

┌────┬────┬───────────────┬─────────────┬────────┬──────────┬────────────────┐
│ 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 Erstellen des Value Objects ProductDimension

Dieses Value Object repräsentiert die Dimensionen des Produkts:

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

2.2 Erstellen des Enums ProductStatus

Dieses Enum definiert den Status des Produkts:

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

3. Hinzufügen neuer Eigenschaften

Mit der Weiterentwicklung des Projekts können bestehende Entitäten bearbeitet werden, um neue Eigenschaften hinzuzufügen. Zum Beispiel fügen wir der Entität Product eine Liste von Bildern hinzu:

lino entity edit

Beim Erstellen der Eigenschaft Images vom Typ List<ProductImage> entsteht die folgende Struktur:

┌────┬────┬───────────────┬────────────────────┬────────┬──────────┬────────────────┐
│ 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 Erstellen der Entität ProductImage

Diese Entität gehört zum Aggregat Product und hat die folgende Struktur:

┌────┬────┬───────────────┬────────────────┬────────┬──────────┬────────────────┐
│ 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. Erstellen von Entitäten für andere Services

Im Service Sales erstellen wir die Entität ProductSnapshot, die durch Integrationsereignisse befüllt wird. Da die ursprüngliche Id der Entität Product aus dem Service Catalog stammt, kann sie hier nicht auto-increment sein.

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

Hinweis: Es wurden nur die wesentlichen Felder in ProductSnapshot für den Service Sales repliziert. Ergänzende Entitäten wie Customer, Order und StockItem werden hier nicht detailliert beschrieben, um die Dokumentation zu vereinfachen.

Erstellen von Events und deren Handlern

Zur Zusammenfassung: Im vorherigen Abschnitt haben wir im modularen Service Catalog.Merchandising die Entitäten Product, Category und ProductImage erstellt, während wir im Service Sales die Entität ProductSnapshot erstellt haben.

Jetzt erstellen wir Domain-Events und Integrations-Events. Das Ziel ist, dass beim Erstellen oder Aktualisieren von Produkten im Service Catalog diese Änderungen an die konsumierenden Services wie Sales und Stock repliziert werden.

1. Erstellen von Domain-Events

Der erste Schritt besteht darin, die Domain-Events ProductCreated und ProductUpdated mit folgendem Befehl zu erstellen:

lino event new

Während der Erstellung können Sie das Event einem Handler zuordnen und gleichzeitig das Auslösen eines Integrations-Events konfigurieren. Dadurch wird die Erstellung des gesamten notwendigen Ablaufs zentralisiert.

┌──────────────────────────────────────────────────────┬────────────────────────────────┐
│ 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                 │
└──────────────────────────────────────────────────────┴────────────────────────────────┘

Auf die gleiche Weise erstellen wir das Event 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                   │
└──────────────────────────────────────────────────────┴────────────────────────────────┘

Damit haben wir:

• Domain-Events erstellt (ProductCreated und ProductUpdated);
• Entsprechende Domain-Event-Handler;
• Integrations-Events automatisch in der Outbox durch den Domain-Event-Handler registriert.

2. Erstellen von Integrations-Event-Handlern

Der nächste Schritt besteht darin, festzulegen, welche Services die Integrations-Events konsumieren. Dafür verwenden wir:

lino event-handler new

Der Erstellungsprozess umfasst:

• Auswahl des Service, Moduls und der Entität, die den Handler enthalten wird;
• Auswahl des zu konsumierenden Integrations-Events und von welchem Service/Modul/Entität es stammt.

Zum Beispiel erstellen wir im Service Sales die Handler für ProductCreated und ProductUpdated, die die Events des Catalog.Merchandising.Product konsumieren:

┌────────────────────────────────────────────┬───────────────────┐
│ 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    │
└────────────────────────────────────────────┴───────────────────┘

Somit haben wir zwei Integrations-Event-Handler im Service Sales, die nur die notwendigen Felder aus den Integrations-Events von Catalog.Merchandising konsumieren. Dies stellt sicher, dass die replizierten Tabellen nur die wesentlichen Daten enthalten und Speicherplatz sowie Performance optimiert werden.

Erstellen von Webseiten, APIs, Commands und Queries

Einer der großen Vorteile von Lino CLI ist die Möglichkeit, Webseiten, APIs, Commands und Queries automatisiert zu erstellen, wodurch der gesamte Entwicklungsfluss vereinfacht wird. Um zu beginnen, führen Sie einfach den folgenden Befehl aus:

lino page new

Während des Prozesses werden Sie:

• Dienst, Modul und Entität auswählen, die Sie bereitstellen möchten;
• Die Felder auswählen, die in der Liste enthalten sein sollen;
• Automatisch Listenseiten (paginierte Grid-Ansicht) und Erstellungs-/Bearbeitungsformulare generieren;
• HttpClient-Klassen für die Nutzung im Frontend generieren;
• Alle erforderlichen REST-APIs erstellen (POST, PUT, PATCH, DELETE und GET);
• Commands und Queries mit den entsprechenden Handlers erstellen, die mit der Datenbank interagieren und den vollständigen CRUD-Fluss gewährleisten.

Mit diesem Befehl erhalten Sie eine funktionale Anwendung, ohne die Benutzeroberfläche, APIs und Geschäftslogik manuell schreiben zu müssen, wobei die Standards und Konsistenz zwischen den Diensten erhalten bleiben.

Für dieses Projekt können wir die integrierten Seiten für die folgenden Entitäten generieren:

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

Nach der Generierung von Seiten, APIs und Commands/Queries ist die Anwendung bereit für eine vollständige Interaktion zwischen Frontend und Backend, wobei Validierungen, Routen und Persistenz bereits automatisch vom Lino CLI konfiguriert werden.

Datenbank-Migrationen erstellen

Nun, da alle Entitäten erstellt wurden, ist es an der Zeit, Migrationen zu generieren, damit die Datenbanken entsprechend dem definierten Modell erstellt oder aktualisiert werden. Lino CLI automatisiert diesen Prozess, integriert sich in Entity Framework und erstellt ausführbare Skripte.

Um eine neue Migration zu erstellen, führen Sie den folgenden Befehl aus:

lino database migrations new

Während der Ausführung müssen Sie:

• Den Service und das Modul auswählen, die die Migration erhalten sollen;
• Eine Beschreibung für diese Migration angeben, z. B. "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 │
└───────────────────────────────────────────┴───────────────────┘

Nach der Bestätigung generiert Lino CLI:

• Eine neue Datenbank-Migration für die aktuelle Service-Version;
• Ein entsprechendes SQL-Skript, das im Layer Infrastructure.Persistence unter dem Pfad /scripts/<version>/<Dateiname> abgelegt wird;
• Die Registrierung der Migrationsversion im Service-Verlauf, wodurch Nachverfolgbarkeit und Konsistenz gewährleistet werden.

Best Practices:

• Erstellen Sie neue Migrationen, wenn Änderungen am Datenmodell vorgenommen werden (neue Entitäten, Eigenschaften oder Änderungen der Beziehungen);
• Überprüfen Sie die generierten SQL-Skripte, bevor Sie sie in der Produktion anwenden;
• Halten Sie die Datenbank-Versionierung mit der Anwendungs-Version synchron, um Konflikte und Synchronisationsprobleme zu vermeiden.

Durch das Befolgen dieses Prozesses stellen Sie sicher, dass die Datenbank stets aktuell und konsistent mit dem in Lino CLI definierten Domänenmodell ist, wodurch Fehler reduziert und die Wartung vereinfacht wird.

Docker-Images erstellen

Nach Abschluss der Codegenerierung für eine bestimmte Version, Durchführung von Tests und Implementierung aller erforderlichen Geschäftsregeln können Sie Docker-Images für die Services und Webanwendungen Ihres Projekts erstellen, um sie später in einem Container-Registry zu veröffentlichen.

Lino CLI vereinfacht diesen Prozess mit dem Befehl:

lino build

Bei der Ausführung sehen Sie eine Liste aller im Projekt verfügbaren Services und Webanwendungen sowie deren aktuelle Versionen:

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|

Sie können einen oder mehrere Services und Webanwendungen auswählen, um Images gleichzeitig zu erstellen. Markieren Sie einfach die gewünschten Elemente.

Anschließend werden Sie aufgefordert auszuwählen, wie die Version der erstellten Images aktualisiert werden soll. Die verfügbaren Optionen sind:

• Aktuelle Version beibehalten – ändert die bestehende Version nicht;
• Patch – erhöht die Patch-Version (z. B.: 0.1.0 → 0.1.1);
• Minor – erhöht die Minor-Version (z. B.: 0.1.0 → 0.2.0);
• Major – erhöht die Major-Version (z. B.: 0.1.0 → 1.0.0).

Nach der Auswahl der Services und Festlegung der Versionserhöhung führt Lino CLI Folgendes aus:

• Build des Codes jedes Services und jeder Webanwendung;
• Erstellung des entsprechenden Docker-Images;
• Anwendung des Tags mit der definierten Version;
• Bereitstellung der Images zur Veröffentlichung in Ihrem Container-Registry.

Am Ende des Prozesses, vorausgesetzt alle Services und Webanwendungen wurden ausgewählt, haben die erzeugten Images die folgende Struktur:

• 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

Hinweis: Dieser Prozess gewährleistet die Konsistenz zwischen Code und Docker-Image-Versionen, erleichtert den Deploy und die Wartung mehrerer Umgebungen und ermöglicht es, jeden Service in unabhängigen Containern isoliert auszuführen.

Versionen in der Anwendung erstellen

Das Erhöhen neuer Versionen für Services oder Webanwendungen ist ein einfacher und zentralisierter Prozess in Lino CLI. Führen Sie einfach den folgenden Befehl aus:

lino version bump

Wie bei der Erstellung von Docker-Images sehen Sie beim Ausführen dieses Befehls eine vollständige Liste aller Services und Webanwendungen Ihres Projekts. Nur die ausgewählten Elemente werden versioniert, die übrigen bleiben unverändert.

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|

Nach der Auswahl der gewünschten Elemente werden Sie aufgefordert, den Typ der Versionserhöhung auszuwählen. Die verfügbaren Optionen sind:

• Patch – kleine Korrekturen ohne funktionale Auswirkungen;
• Minor – Hinzufügen neuer Funktionen, die mit früheren Versionen kompatibel sind;
• Major – Änderungen, die die Kompatibilität mit früheren Versionen brechen können.

Es ist wichtig zu beachten, dass die Versionen von Services und Webanwendungen direkten Einfluss haben auf:

• Die Tags der Docker-Images;
• Die Ordner, die zum Speichern von durch Datenbankmigrationen generierten Skripten verwendet werden;
• Das Release-Management und die Projekt-Historie.

Damit schließen wir die Schritt-für-Schritt-Anleitung zu allen wesentlichen Befehlen für den Aufbau eines Webprojekts mit Lino CLI ab, von der Installation, Erstellung von Services, Entitäten, Events und Seiten bis hin zur Erstellung von Docker-Images und Versionierung.

Vergessen Sie nicht, unseren YouTube-Kanal zu abonnieren, um detaillierte Tutorials, praktische Demonstrationen und Tipps zur Nutzung des Tools zu erhalten – von einfachen Operationen bis hin zu erweiterten Funktionen.