Projektstrukturierung

Grundlage der Lösung erstellen

Der Befehl lino project new erstellt die technische Grundlage einer neuen .NET-Lösung. Führen Sie ihn nach Installation und Authentifizierung der CLI in einem leeren Verzeichnis aus.

lino project new --name <ProjectName>

Das Argument <ProjectName> steht für den tatsächlichen Namen der Lösung. Dieser Name wird Teil von namespaces, assemblies, Pfaden, Konfigurationen, Artefakten und Referenzen zwischen Komponenten; wählen Sie deshalb einen kurzen, stabilen und repräsentativen Namen.

Der interaktive Assistent fragt Entscheidungen ab, die die Struktur und das runtime-Verhalten der gesamten Lösung beeinflussen:

• Projekt-Namespace: technische Root-Identität, die von den generierten Projekten verwendet wird.
• Anzeigename: lesbarer Name, der in generierten Metadaten und benutzersichtbaren Stellen verwendet wird.
• Sprache und stack: derzeit C# mit .NET 10 und Aspire.
• Code-Analyzer: aktivieren gemeinsame Pakete und Regeln, um Konsistenz und Qualität ab dem bootstrap zu sichern.
• CQRS: bereitet die Application-Schicht darauf vor, commands und queries zu trennen, orchestriert durch die ausgewählte mediator-Bibliothek.
• Basisklassen in der Lösung: steuert, ob gemeinsame Abstraktionen lokal innerhalb der Lösung generiert werden.
• Verteilter Cache: legt fest, ob Microsoft.Extensions.Caching.Hybrid nur den lokalen Speicher der Instanz oder zusätzlich eine verteilte Schicht mit von Aspire konfiguriertem Redis verwendet.
• Asynchrone Kommunikation: aktiviert RabbitMQ mit MassTransit und die Messaging/outbox-Bausteine, die von Integrationsereignissen verwendet werden.
• Datensprache: Sprache, die während der Generierung zur Beschreibung von Domain-Metadaten verwendet wird.
• Von der Anwendung unterstützte Kulturen: Lokalisierungsressourcen, die für UI-Texte, Validierungen, Fehler und API-Antworten generiert werden.
• Standardkultur: Hauptsprache, die verwendet wird, wenn die Anwendung einen fallback benötigt.

Nach der Bestätigung generiert Lino eine auf Wachstum ausgelegte Lösung. Ein minimales Projekt startet mit Aspire, gemeinsamen Schichten und Tests für den Shared-Bereich:

<ProjectName>/
├── <ProjectName>.slnx
├── Directory.Build.props
├── Directory.Packages.props
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── <ProjectName>.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── <ProjectName>.ServiceDefaults.csproj
│   └── Services/
│       └── Shared/
│           ├── Api/
│           │   └── <ProjectName>.Shared.Api.csproj
│           ├── Application/
│           │   └── <ProjectName>.Shared.Application.csproj
│           ├── Domain/
│           │   └── <ProjectName>.Shared.Domain.csproj
│           ├── Infrastructure/
│           │   └── <ProjectName>.Shared.Infrastructure.csproj
│           ├── Infrastructure.Persistence/
│           │   └── <ProjectName>.Shared.Infrastructure.Persistence.csproj
│           └── Integration.Events/          (wenn Messaging vorhanden ist)
│               └── <ProjectName>.Shared.Integration.Events.csproj
└── tests/
    └── Services/
        └── Shared/
            └── UnitTests/
                ├── Domain/
                │   └── <ProjectName>.Shared.Domain.UnitTests.csproj
                └── Application/
                    └── <ProjectName>.Shared.Application.UnitTests.csproj

Die Rolle der Shared-Projekte

Shared enthält Plattformcode, der von der Lösung geteilt wird. Es ist kein fachlicher Service. Nutzen Sie diesen Bereich für querschnittliche Abstraktionen, gemeinsame Fehler, Lokalisierungsinfrastruktur, Basisverträge der Anwendung, Persistenz-helper, API-Erweiterungen, Host-Integration, Observability und wiederverwendbare technische Utilities.

Vermeiden Sie Geschäftsregeln in Shared. Wenn eine Regel zu einer bestimmten Fähigkeit der Anwendung gehört, sollte sie im Service oder Modul liegen, das diese Verantwortung besitzt. Ziel von Shared ist es, technische Wiederholung zu reduzieren, nicht eine Abkürzung zur Kopplung unterschiedlicher Domains zu werden.

Aspire und Infrastrukturentscheidungen

AppHost komponiert die Lösung und ihre runtime-Ressourcen. Wenn Redis, RabbitMQ, SQL Server, PostgreSQL, Redis Insight, Services, WebApps oder workers hinzugefügt werden, wird Aspire zum lokalen Orchestrierungspunkt. Das vereinfacht Ausführung, service discovery, Logs, Metriken, traces und Ressourcenvisualisierung während der Entwicklung.

ServiceDefaults zentralisiert Hosting-Muster wie service discovery, health checks, Resilienz, logging, Metriken, tracing und OpenTelemetry-Integration. Statt dass jeder Service dies isoliert konfiguriert, startet die Lösung mit einem gemeinsamen Kompositionspunkt.

Code-Analyzer

Statische Code-Analyzer prüfen den Code während der Entwicklung und machen Probleme vor der Ausführung sichtbar: Stilinkonsistenzen, fragile Muster, Refactoring-Möglichkeiten, mögliche Bugs und Sicherheitswarnungen.

Wenn Sie Analyzer in lino project new aktivieren, startet die Lösung bereits mit zentral konfigurierten Paketen wie StyleCop.Analyzers, SonarAnalyzer.CSharp und Roslynator.Analyzers. Dadurch muss nicht jedes Projekt selbst entscheiden, welcher Qualitätsstandard gilt.

• Qualitätsverbesserung: hält Code lesbar, konsistent und an den Standards der Lösung ausgerichtet.
• Fehlervermeidung: weist früh auf Probleme hin, bevor sie manuelle Tests oder Produktion erreichen.
• Standardisierung: reduziert Stilunterschiede zwischen Services, Modulen und Teams.
• Unterstütztes Refactoring: hebt mögliche Vereinfachungen und Modernisierungsmöglichkeiten in C# hervor.

Verteilter Cache, Hybrid-Cache und Redis

Lino bereitet die Lösung darauf vor, Microsoft.Extensions.Caching.Hybrid zu verwenden, die Microsoft-Bibliothek, die Cache-Operationen über HybridCache zentralisiert. Diese Abstraktion erlaubt handlers, Application Services und Infrastrukturkomponenten, Abfrageergebnisse, Berechtigungen, Einstellungen oder unterstützende Daten zu speichern, ohne Cache-Implementierungsdetails im Code zu verteilen.

Wenn Sie bei der Projekterstellung keinen verteilten Cache aktivieren, bleibt HybridCache verfügbar, arbeitet aber nur mit dem lokalen Speicher der laufenden Instanz. Dieser Modus ist einfach und ausreichend für lokale Szenarien, kleine Umgebungen oder Anwendungen mit einer einzelnen Replik, aber jeder Prozess hält seinen eigenen Cache und Daten werden nicht zwischen Instanzen geteilt.

Wenn Sie verteilten Cache aktivieren, fügt Lino Redis zu den Aspire-Ressourcen hinzu und konfiguriert die Infrastruktur für eine gemeinsame Cache-Schicht. Mit Redis können mehrere Instanzen desselben Service dieselbe Schicht abfragen, wiederholte Lesezugriffe auf Datenbanken, interne APIs oder Integrationen reduzieren und das Projekt auf horizontale Skalierung vorbereiten.

• Performance: reduziert Antwortzeiten bei wiederholten Lesezugriffen und unterstützenden Operationen.
• Skalierbarkeit: erlaubt unterschiedlichen Instanzen, zwischengespeicherte Daten zu teilen.
• Verfügbarkeit: entkoppelt einen Teil der Leselast von der primären Datenbank.
• Betriebskosten: reduziert wiederholte Verarbeitung in hochvolumigen Abfragen und Integrationen.

Diese Entscheidung wird in lino project new getroffen, weil sie die Grundlage der Umgebung verändert: AppHost-Ressourcen, lokale secrets, Pakete, Infrastrukturkonfiguration und die im Aspire-Dashboard angezeigte Ausführungstopologie.

Asynchrone Kommunikation

Asynchrone Kommunikation erlaubt Services, Modulen und Komponenten, auf Fakten des Systems zu reagieren, ohne den Hauptfluss der Operation zu blockieren. Sie ist besonders nützlich, wenn der Produzent nicht von der unmittelbaren Verfügbarkeit des Konsumenten abhängen soll oder wenn eine Aktion spätere Effekte auslösen muss, etwa Benachrichtigungen, Projektionen, externe Integrationen oder Synchronisierung zwischen Kontexten.

Wenn Sie asynchrone Kommunikation aktivieren, fügt Lino RabbitMQ zu Aspire hinzu und konfiguriert MassTransit zusammen mit den Messaging- und outbox-Bausteinen, die von Integrationsereignissen verwendet werden. Ereignisse, die von Services oder Modulen veröffentlicht werden, sind dadurch als explizite Verträge in Integration.Events repräsentiert und können resilienter verarbeitet werden.

• Performance: erlaubt dem Haupt-Use-Case fortzufahren, ohne auf den Abschluss aller Konsumenten zu warten.
• Skalierbarkeit: verteilt Verarbeitung über Konsumenten und Queues und fängt Lastspitzen kontrollierter ab.
• Resilienz: ermöglicht Wiederverarbeitung und reduziert Nachrichtenverlust in Kombination mit outbox.
• Entkopplung: vermeidet direkte Abhängigkeit zwischen Produzent und Konsument, wenn keine sofortige Antwort erforderlich ist.

Verwenden Sie Integrationsereignisse, wenn ein Fehler des Konsumenten die Transaktion des Produzenten nicht rückgängig machen soll. Wenn der Konsument sofort antworten muss, um den Use Case abzuschließen, bevorzugen Sie eine explizite synchrone Integration und behandeln Sie Verfügbarkeit, timeout und fallback als Teil des Vertrags.

Lokalisierung und Kulturen

Wenn Kulturen ausgewählt werden, generiert Lino Ressourcen, damit Nachrichten, Validierungen, labels, Fehler und UI-Texte von Beginn an lokalisiert werden können. Das vermeidet, Internationalisierung als späten Patch zu behandeln, nachdem strings bereits über Endpunkte, handlers und Komponenten verteilt sind.

Grundlage validieren und zu Services wechseln

Stellen Sie nach der Generierung Abhängigkeiten wieder her, bauen Sie die Lösung und führen Sie den Aspire-Host aus:

dotnet restore <ProjectName>.slnx
dotnet build <ProjectName>.slnx
dotnet run --project src/Aspire/AppHost/<ProjectName>.AppHost.csproj

In diesem Stadium ist die Lösung noch eine Grundlage. Öffnen Sie das Projekt im Editor, prüfen Sie die von Aspire erstellten Ressourcen, bestätigen Sie die Entscheidungen zu Cache, Messaging, Lokalisierung und Codequalität und wechseln Sie dann zu den Services, die die Geschäftsfähigkeiten der Anwendung repräsentieren.

Services erstellen und verwalten

Ein Service ist eine Grenze für runtime und ownership. In Lino können Services unabhängige APIs in einem verteilten System oder größere Geschäftsbereiche innerhalb einer Lösung repräsentieren, die schrittweise wachsen kann.

Nachdem Sie die Projektgrundlage erstellt haben, fügen Sie Services hinzu mit:

lino service new

Der Service-Assistent fragt Folgendes ab:

• Service-Namespace: technischer Name, der in Ordnern, Projekten und namespaces verwendet wird.
• Anzeigename: lesbarer Name des Service.
• Service-Typ: wählen Sie zwischen einfach und modular.
• Datenbankprovider: wählen Sie SQL Server oder PostgreSQL für die Datenbank des Service.
• Architekturstil: derzeit Clean Architecture für einfache Services.
• Strongly Typed IDs: legt bei einfachen Services fest, ob Bezeichner als dedizierte Typen generiert werden.

Service-Typen

Einfacher Service: eine direktere Struktur für eine Geschäftsfähigkeit mit klarer Grenze. Das ist eine gute Wahl für eine fokussierte API, einen Microservice oder einen Bereich, der klein genug ist, um als Einheit weiterentwickelt zu werden.

Modularer Service: eine Struktur für größere Systeme, modulare Monolithen oder runtimes, die mehrere unabhängige Fähigkeiten hosten müssen. Module verbessern Organisation und Skalierbarkeit des Modells, erfordern aber mehr Disziplin bei Abhängigkeiten.

Unabhängig vom Typ besitzt jeder Service seine eigene Datenbank. Bei einfachen Services wird die Entscheidung über Strongly Typed IDs auf Service-Ebene getroffen; bei modularen Services pro Modul.

Einfacher Service

Ein einfacher Service legt seine Schichten direkt unter src/Services/<ServiceName> ab. Verwenden Sie diese Struktur, wenn die Geschäftsfähigkeit eine klare Grenze besitzt und keine mehreren isolierten Module innerhalb desselben runtime benötigt. Sie funktioniert gut für eine fokussierte API, einen Microservice oder einen Domain-Bereich, der klein genug ist, um als Einheit weiterentwickelt zu werden.

src/Services/<ServiceName>/
├── Domain/
│   └── <ProjectName>.<ServiceName>.Domain.csproj
├── Application/
│   └── <ProjectName>.<ServiceName>.Application.csproj
├── Infrastructure.Persistence/
│   └── <ProjectName>.<ServiceName>.Infrastructure.Persistence.csproj
├── Infrastructure/
│   └── <ProjectName>.<ServiceName>.Infrastructure.csproj
├── Api/
│   └── <ProjectName>.<ServiceName>.Api.csproj
├── Integration.Events/              (wenn Messaging vorhanden ist)
│   └── <ProjectName>.<ServiceName>.Integration.Events.csproj
├── Api.Contracts/                   (wenn typisierter HTTP-Konsum vorhanden ist)
│   └── <ProjectName>.<ServiceName>.Api.Contracts.csproj
└── Api.Client/                      (wenn typisierter HTTP-Konsum vorhanden ist)
    └── <ProjectName>.<ServiceName>.Api.Client.csproj
tests/Services/<ServiceName>/
├── UnitTests/
│   ├── Domain/
│   │   └── <ProjectName>.<ServiceName>.Domain.UnitTests.csproj
│   └── Application/
│       └── <ProjectName>.<ServiceName>.Application.UnitTests.csproj
└── IntegrationTests/
    └── <ProjectName>.<ServiceName>.IntegrationTests.csproj

Die Schichten haben unterschiedliche Verantwortlichkeiten: Domain schützt Geschäftsregeln und Invarianten; Application orchestriert Use Cases; Infrastructure.Persistence enthält Entity Framework Core, Repositories, Unit of Work und migrations; Infrastructure enthält technische Integrationen; und Api passt HTTP an Use Cases an.

Die Projekte Api.Contracts und Api.Client erscheinen, wenn typisierter HTTP-Konsum vorhanden ist, besonders in Lösungen mit einer Blazor Web App. Das erste bündelt requests, responses, DTOs, öffentliche Typen und gemeinsame Client-Interfaces; das zweite stellt die HTTP-Implementierung dieser Interfaces mit HttpClient bereit, damit Blazor die generierten APIs ohne doppelte Verträge konsumiert.

Integration.Events erscheint, wenn die Lösung Messaging aktiviert hat. Es enthält Integrationsereignisse, die von anderen Modulen, Services oder Systemen veröffentlicht und konsumiert werden, normalerweise zusammen mit Messaging- und outbox-Infrastruktur.

Modularer Service

Ein modularer Service eignet sich für modulare Monolithen oder für ein runtime, das mehrere bounded contexts hostet. Der Service selbst besitzt Host, gemeinsame Infrastruktur und Datenbankprovider; Geschäftsregeln leben innerhalb der Module.

src/Services/<ServiceName>/
├── Host/
│   └── <ProjectName>.<ServiceName>.Host.csproj
├── Infrastructure/
│   └── <ProjectName>.<ServiceName>.Infrastructure.csproj
└── Modules/
tests/Services/<ServiceName>/
└── Modules/

Host komponiert Module, Einstellungen, Endpunkte und gemeinsame Infrastruktur dieses Service. Er sollte keine Geschäftsregeln enthalten. Das Projekt Infrastructure auf Service-Ebene stellt technische Kompositionsunterstützung bereit, die von Modulen geteilt wird.

Wenn ein Modul hinzugefügt wird, erscheinen die Projekte Domain, Application, Infrastructure.Persistence, Infrastructure und Api innerhalb von Modules/<ModuleName> und erhalten die interne Grenze. Api.Contracts, Api.Client und Integration.Events folgen denselben Bedingungen: typisierter HTTP-Konsum für Blazor/API clients und aktiviertes Messaging für Integrationsereignisse.

Datenbank-ownership

Jeder Service besitzt seine eigene Datenbank. In einer Lösung mit mehreren Services kann ein Service PostgreSQL verwenden, während ein anderer SQL Server verwendet. Diese Entscheidung kann je nach Domain-Bedarf, Performance, Betrieb, Reife des Teams oder Integration mit vorhandener Infrastruktur variieren.

In einem modularen Service gehört die Datenbank zum Service als runtime, aber die Module sind durch schema, Persistenzprojekte und eigene migrations isoliert. Ein Modul sollte Tabellen eines anderen Moduls nicht direkt abfragen, selbst wenn die Tabellen in derselben physischen Datenbank liegen.

Zwischen einfach und modular wählen

Wählen Sie die kleinste Struktur, die die Grenze schützt. Ein einfacher Service reicht aus, wenn es eine einzige Domain-Grenze gibt. Ein modularer Service ist sinnvoll, wenn mehrere Fähigkeiten runtime, deploy oder Transaktion teilen müssen, aber Modelle, Persistenz, APIs und Tests weiterhin getrennt bleiben sollen.

Architekturstil

Von Lino generierte Services folgen Clean Architecture, um Geschäftsregeln von technischen Details zu trennen. Die Domain-Schicht muss HTTP, Entity Framework Core, Messaging, UI oder externe Provider nicht kennen; diese Anliegen bleiben an den Rändern der Anwendung.

• Entkopplung: zentrale Regeln hängen nicht von Frameworks oder Auslieferungsmechanismen ab.
• Wartbarkeit: Änderungen an Infrastruktur bleiben tendenziell von Geschäftsregeln isoliert.
• Testbarkeit: Use Cases und Domain-Code können mit weniger externen Abhängigkeiten getestet werden.
• Evolution: technische Details können mit geringerer Auswirkung auf den Kern des Service ersetzt werden.

Clean Architecture und Strongly Typed IDs

Generierte Services folgen Clean Architecture, damit Geschäftscode nicht von HTTP, EF Core, Messaging, UI oder Infrastrukturdetails abhängt. Diese Trennung macht Tests direkter, reduziert Kopplung und erlaubt, technische Details zu ersetzen, ohne zentrale Regeln neu zu schreiben.

Strongly Typed IDs erhöhen die Sicherheit, indem sie versehentliches Vermischen von Bezeichnern verhindern. Statt irgendein Guid, long oder int zu akzeptieren, kann die Domain mit einem eigenen Typ für jede Entität oder jedes Aggregat arbeiten, normalerweise im Format <EntityName>Id. Das verhindert, dass der Bezeichner einer Entität übergeben wird, wo ein anderer erwartet wurde, und macht Signaturen in commands, queries, Entitäten, handlers und Mappings aussagekräftiger.

• Typsicherheit: verhindert, dass Bezeichner unterschiedlicher Entitäten versehentlich vermischt werden.
• Klarheit: macht Signaturen und Verträge ausdrucksstärker als lose primitive Typen.
• Refactoring: konzentriert Änderungen an Format oder Serialisierung im entsprechenden ID-Typ.
• Fehlerreduzierung: macht falsche Verwendungen nach Möglichkeit bereits zur Compilezeit sichtbar.

Integration zwischen Services

Wenn ein Service auf einen anderen reagieren muss, bevorzugen Sie Integrationsereignisse, explizite HTTP-Integrationen oder bewusst replizierte Daten. Direkter Zugriff auf die Datenbank eines anderen Service erzeugt strukturelle Kopplung, erschwert migrations und macht unabhängige deploys riskanter.

Nächste Schritte für modulare Services

Nachdem ein modularer Service erstellt wurde, ist der nächste Schritt, Module mit lino module new hinzuzufügen. Jedes Modul sollte eine eigene Geschäftsfähigkeit repräsentieren, mit Domain, Application, Persistenz, API, Tests und Integrationen, die die interne Grenze des Service erhalten.

Module erstellen und verwalten

Module existieren nur innerhalb modularer Services. Ein Modul repräsentiert eine fachliche Grenze innerhalb desselben runtime: Es besitzt sein eigenes Domain-Modell, eigene Use Cases, Persistenz, API-Oberfläche, Integrationsereignisse, Tests und ein eigenes Datenbankschema.

Verwenden Sie Module, wenn der Service mehr als eine Geschäftsfähigkeit hosten muss, ohne Entitäten, Regeln, migrations und Verträge zu vermischen. In einem modularen Monolithen kann alles im selben Prozess laufen, aber interne Grenzen bleiben wichtig: Echte Isolation ist Kontrolle über Abhängigkeiten, nicht nur Ordnertrennung.

lino module new --service <ServiceName>

Während der Erstellung fragt der Assistent Folgendes ab:

• Service: der modulare Service, der das Modul hostet. Lino erlaubt nicht, Module innerhalb einfacher Services zu erstellen, weil diese nicht die für interne Isolation erforderliche Struktur besitzen.
• Modul-Namespace: der technische Name, der in Ordnern, namespaces, assemblies und Projekten verwendet wird.
• Anzeigename: der lesbare Modulname für Stellen, die für Menschen bestimmt sind.
• Strongly Typed IDs: legt fest, ob innerhalb des Moduls generierte Bezeichner dedizierte Typen verwenden, normalerweise im Format <EntityName>Id.

Nach der Bestätigung fügt Lino das Modul innerhalb des Service hinzu, ohne die Architekturgrenze aufzulösen:

src/Services/<ServiceName>/
├── Host/
├── Infrastructure/
└── Modules/
    └── <ModuleName>/
        ├── Domain/
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Domain.csproj
        ├── Application/
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Application.csproj
        ├── Infrastructure.Persistence/
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Infrastructure.Persistence.csproj
        ├── Infrastructure/
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Infrastructure.csproj
        ├── Api/
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Api.csproj
        ├── Integration.Events/              (wenn Messaging vorhanden ist)
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Integration.Events.csproj
        ├── Api.Contracts/                   (wenn typisierter HTTP-Konsum vorhanden ist)
        │   └── <ProjectName>.<ServiceName>.<ModuleName>.Api.Contracts.csproj
        └── Api.Client/                      (wenn typisierter HTTP-Konsum vorhanden ist)
            └── <ProjectName>.<ServiceName>.<ModuleName>.Api.Client.csproj
tests/Services/<ServiceName>/Modules/<ModuleName>/
├── UnitTests/
│   ├── Domain/
│   │   └── <ProjectName>.<ServiceName>.<ModuleName>.Domain.UnitTests.csproj
│   └── Application/
│       └── <ProjectName>.<ServiceName>.<ModuleName>.Application.UnitTests.csproj
└── IntegrationTests/
    └── <ProjectName>.<ServiceName>.<ModuleName>.IntegrationTests.csproj

Verantwortlichkeiten der generierten Artefakte

Datenbankstruktur

Die Datenbank bleibt an den Service gebunden, nicht isoliert an das einzelne Modul. Innerhalb eines modularen Service wird jedes Modul durch sein eigenes schema in der zugehörigen Datenbank repräsentiert, mit eigenem Persistenzprojekt und eigenen migrations. Das bietet Isolation und Organisation, ohne mehrere physische Datenbanken für jedes Modul zu verlangen.

Isolation und Unabhängigkeit zwischen Modulen

Ein Modul sollte nicht direkt auf den DbContext, die Entitäten, Repositories oder internen Services eines anderen Moduls zugreifen. Jedes Modul besitzt sein eigenes Modell und seine eigene Persistenz. Wenn ein anderes Modul Daten benötigt, verwenden Sie eine explizite Integration, statt die Grenze über interne Implementierungsdetails zu überschreiten.

Das verhindert, dass eine scheinbar lokale Änderung einen anderen Bereich des Systems bricht. Wenn ein konsumierendes Modul Daten abfragen muss, die zu einem anderen Modul gehören, sollte es nicht von der vollständigen Entität des Quellmoduls abhängen. Es kann eine shadow entity mit den minimal erforderlichen Daten für den eigenen Use Case halten, gespeist durch Integration oder Ereignis.

Vorteile dieser Entkopplung:

• Isolation: jedes Modul kann Regeln, Persistenz und Tests weiterentwickeln, ohne interne Details eines anderen Moduls zu überschreiten.
• Organisation: die Anwendung respektiert bounded contexts und macht ownership explizit.
• Flexibilität: Module können mit geringeren Auswirkungen auf den Rest des Service hinzugefügt, entfernt oder refaktoriert werden.
• Testbarkeit: jedes Modul kann unabhängiger validiert werden, was das Vertrauen in Änderungen erhöht.

Kommunikation zwischen Modulen

Verwenden Sie explizite Verträge für die Kommunikation. Für Aufrufe innerhalb desselben runtime kann eine interne Integration Verträge in Integration.Contracts und, wenn generiert, eine in-process-Implementierung bereitstellen. Für Aufrufe zwischen runtimes verwenden Sie HTTP-Integration. Für asynchrone Weitergabe veröffentlichen Sie Integrationsereignisse in Integration.Events und verwenden die Messaging/outbox-Infrastruktur, wenn die Veröffentlichung Teil einer transaktionalen Operation ist.

Schemas, migrations und Datenbank

In einem modularen Service teilen sich die Module den Datenbankprovider des Service, aber jedes Modul wird durch sein eigenes schema und sein eigenes Projekt Infrastructure.Persistence repräsentiert. Migrations werden pro Modul generiert, sodass die Datenbankentwicklung an der fachlichen Grenze ausgerichtet bleibt.

Diese Trennung erlaubt jedem Modul, seine Tabellen, seeds, Indizes und foreign keys weiterzuentwickeln, ohne die Datenbank des Service in ein einziges, von allen geteiltes Modell zu verwandeln. Das schema ist eine technische Grenze, die die fachliche Grenze stärkt, selbst wenn Module im selben Prozess laufen und dieselbe physische Datenbank verwenden.

Gute Modulgrenzen

Erstellen Sie Module rund um Geschäftsfähigkeiten, nicht rund um technische Schichten. Ein guter Modulname sollte eine für die Domain erkennbare Verantwortung beschreiben, etwa einen Bereich, Prozess oder eine Fähigkeit mit eigenen Regeln. Vermeiden Sie generische Namen wie Common, Core oder Utilities für Geschäftsregeln, weil sie ownership verbergen und dazu neigen, zu übermäßig geteilten Abhängigkeiten zu werden.

• Kohäsion: das Modul sollte Sprache, Regeln und Daten enthalten, die sich gemeinsam ändern.
• Autonomie: es sollte möglich sein, das Modul zu testen und weiterzuentwickeln, ohne auf interne Entitäten eines anderen Moduls zuzugreifen.
• Klare Verträge: Daten, die außerhalb des Moduls benötigt werden, sollten über API, Integration, Ereignis oder shadow entity offengelegt werden, nicht durch direkten Datenbankzugriff.
• Geringe Kopplung: wenn zwei Module ständig dieselben Entitäten ändern müssen, muss die Grenze wahrscheinlich überprüft werden.

Nachdem die Module erstellt wurden, zeigen die nächsten Dokumentationsthemen, wie Entitäten, Value Objects, enumerations, commands, queries, APIs, Ereignisse, Integrationen und migrations innerhalb dieser Grenzen modelliert werden.