Architekturentscheidungen vor der Codegenerierung

Projekttyp

Vor dem Laufen lino project new, definieren Sie das Ziel des Systems. Ein internes Verwaltungsprojekt, ein mandantenfähiges SaaS, ein öffentliches API und eine verteilte Plattform haben unterschiedliche Anforderungen.

• Einfache Anwendung: wenige Kontexte, einmalige Bereitstellung und geringer Bedarf an betrieblicher Unabhängigkeit.
• Modularer Monolith: mehrere Module im selben Prozess, mit klaren Grenzen und geringeren Betriebskosten.
• Mikrodienste: separate Services, unabhängige Bereitstellung, asynchrone Kommunikation und größere betriebliche Komplexität.
• SaaS: erfordert Mieterisolierung, starke Sicherheit, Secrets, Tarifbegrenzung, Beobachtbarkeit und klare Abrechnungs-/Betriebsentscheidungen.

In diesem Beschluss wird auch festgelegt, welche Anliegen am ersten Tag auftreten sollen. Ein SaaS kann den Mieter nicht als verspätetes Detail behandeln; ein öffentlicher API kann nicht ohne Tarifbegrenzung und klare Verträge entstehen; Eine Lösung mit Ereignissen muss über Outbox, Idempotenz und Beobachtbarkeit nachdenken. Eine Anwendung mit mehreren Kulturen sollte von Anfang an verstreute Zeichenfolgen vermeiden.

Notieren Sie beim Erstellen der Grundlage die wichtigsten Auswahlmöglichkeiten: unterstützte Kulturen, verteilter Cache, asynchrone Kommunikation, Code-Analyzers, Datenbanktyp, Web-App-Präsenz, Authentifizierung, Tenant und Worker. Diese Optionen betreffen Packages, Templates, AppHost, Parameter, Secrets, generierte Projekte und den Aufwand, der für eine spätere Änderung der Architektur erforderlich ist.

Modulare vs. modulare Monolith-Microservices

Der modulare Monolith ermöglicht es Ihnen, die Domäne in Module mit klaren internen Verträgen zu organisieren, wodurch Build, Debug und Bereitstellung einfacher bleiben. Microservices lohnen sich nur, wenn es triftige Gründe gibt: unabhängige Skalierung, separate Teams, stabile Geschäftsgrenzen oder unterschiedliche betriebliche Anforderungen.

Mit einem modularen Monolithen zu beginnen bedeutet nicht, die Architektur zu ignorieren. Es bedeutet, eine einfache Bereitstellung beizubehalten, während die Domäne noch entdeckt wird, aber interne Grenzen zu schaffen, die verhindern, dass alles zu einer einzigen Masse von Entitäten, Servicesn und gemeinsam genutzten Tabellen wird. Das ist der Unterschied zwischen „einfach beginnen“ und „ohne Struktur beginnen“.

Lino unterstützt beide Pfade. Die Entscheidung muss sich an der Domäne und der operativen Kapazität des Teams orientieren, nicht nur an den technischen Vorlieben. Microservices erfordern Bereitstellungsautomatisierung, verteilte Observability, Vertragsversionierung, Netzwerkfehlertoleranz, Messaging, Wiederverarbeitung und Datenverwaltung. Wenn das Team dies noch nicht sicher betreiben kann, erhöht eine zu frühe Verteilung oft das Risiko.

Verwenden Sie modulare Monolithen, wenn es vorrangig darum geht, die Domäne zu erlernen, das Produkt zu validieren und den Betrieb kontrollierbar zu halten. Nutzen Sie Microservices, wenn betriebliche Unabhängigkeit bereits ein konkreter Bedarf ist: separater Maßstab, Teams mit echten Eigentümern, unabhängiger Release-Zyklus oder inkompatible Infrastrukturanforderungen zwischen Teilen des Systems.

Leistungs- und Modulgrenzen

Ein gutes Limit reduziert die Kopplung und macht klar, wer der Eigentümer jeder Regel ist. Vermeiden Sie die Erstellung von Servicesn pro Tabelle oder pro Bildschirm. Services und Module müssen Geschäftsfähigkeiten darstellen.

• Katalog: Produkte, Kategorien, kommerzielle Informationen und vom Vertrieb konsultierte Daten.
• Verkäufe: Bestellungen, Warenkorb, angewendete Preise, Schnappschüsse und kommerzieller Ablauf.
• Aktie: Verfügbarkeit, Reservierungen und Bewegungen.
• Sicherheit: Benutzer, Rollen, Berechtigungen, Authentifizierung und Token.

Ein guter Grenzwert hat seine eigene Sprache, Regeln, die sich gemeinsam ändern, Daten unter eindeutigem Eigentum und explizite Verträge zur Kommunikation mit anderen Kontexten. Ein fehlerhafter Grenzwert erscheint normalerweise als „gemeinsames“ Modul, als eine Einheit, die von mehreren Bereichen gemeinsam genutzt wird, als eine von allen konsultierte Tabelle oder als ein Dienst, der nur erstellt wurde, weil es einen neuen Bildschirm gab.

Wenn ein Modul Daten von einem anderen benötigt, wählen Sie zwischen API, Integration Event, Shadow Entity oder Neumodellierung der Grenze. Der direkte Zugriff auf die Datenbank eines anderen Moduls ist ein Zeichen für eine strukturelle Kopplung. Selbst wenn zwei Module im selben Prozess ausgeführt werden und dieselbe physische Datenbank verwenden, müssen das Schema, die Persistence-Projekte und die Verträge die Geschäftsgrenze schützen.

• Gutes Grenzwertzeichen: Das Modul kann seine Entitäten und Migrationen weiterentwickeln, ohne dass ein anderes Modul aufgrund interner Details eine Neukompilierung erzwingen muss.
• Schwaches Schwellensignal: Eine einfache Änderung an einer Entität erfordert die Überprüfung von Bildschirmen, Abfragen und Modulhandlern, die diese Entität nicht kennen sollten.
• Verstecktes Abhängigkeitszeichen: Der Consumer muss „zu viel wissen“ über Tabellen, technische Bereiche oder die internen Regeln des Producers.

Bewusste technische Schulden

Technische Schulden sind nicht irgendeine Unvollkommenheit. Es ist eine Entscheidung, die Qualität im Wissen um die zukünftigen Kosten aufzuschieben. Das Problem besteht darin, Schulden ohne Namen, ohne Eigentümer und ohne Zahlungsplan zu schaffen.

In einem SaaS oder modularen System ist die gefährlichste technische Schuld nicht nur eine lange Methode. Es sind die Schulden, die die Evolution einschränken: Module, die sich nicht separat ändern können, Tenantendaten ohne zuverlässige Isolierung, Secrets innerhalb des Repositorys, sensible Endpunkte ohne Grenzen, Ereignisse ohne erneute Verarbeitung oder Integrationen ohne klaren Vertrag.

• Dokumentieren Sie Abkürzungen, die während der Generierung und Anpassung genommen wurden.
• Führen Sie Build und Test aus, bevor Sie mit der nächsten Generationsstufe fortfahren.
• Vermeiden Sie die Behebung von Problemen, die durch wiederholte lokale Hacks entstehen. Passen Sie das Muster oder die Vorlage an, wenn das Muster falsch ist.

Behandeln Sie jede architektonische Entscheidung als überprüfbar. Wenn Sie die Nachrichtenübermittlung nicht aktivieren möchten, beachten Sie, dass aktuelle Abläufe nicht auf asynchroner Verarbeitung basieren. Wenn Sie eine Spalte pro Tenant auswählen, stellen Sie Filter und Tests sicher. Wenn Sie sich für die synchrone Integration entscheiden, gehen Sie beim Entwurf von Zeitüberschreitungen, Nichtverfügbarkeit und Vertragsfehlern aus.

Kommunikationsstrategien

Wählen Sie die Kommunikation entsprechend dem tatsächlichen Bedarf an Konsistenz, Latenz, Rückverfolgbarkeit und Kopplung. Die Hauptfrage lautet nicht „Welche Technologie soll verwendet werden?“, sondern „Der Producer braucht jetzt die Antwort, sollte der Consumer den Vorgang nicht abbrechen und wem gehören die Daten?“

In modularen Systemen besteht der häufigste Fehler darin, die Kommunikation in eine versteckte Abhängigkeit umzuwandeln: Ein Modul fragt die Tabelle eines anderen ab, verwendet eine interne Entität wieder, fügt ein externes Repository ein oder erstellt einen synchronen Aufruf, ohne Fehler zu behandeln. Das erscheint zunächst produktiv, macht aber jede weitere Änderung riskanter, da die Grenze nicht mehr eindeutig ist.

• Synchroner Aufruf: Gut für sofortige Abfragen und akzeptable Abhängigkeit. Vermeiden Sie lange Kaskaden.
• Domain-Ereignis: interne Reaktion innerhalb der gleichen Anwendungsgrenze.
• Integration Event: Kommunikation zwischen Modulen, Servicesn oder Systemen, normalerweise mit Outbox.
• Shadow Entity: Mindestens lokale Kopie für Konsultation und Validierung, ohne direkt vom Producer abhängig zu sein.
• Externe HTTP-Integration: Geeignet für Services von Drittanbietern, mit Timeout, Wiederholungsversuchen, Protokollen und Fehlerbehandlung.

Wenn die Regel eine sofortige Aktualisierung erfordert, verwenden Sie synchrones Streaming oder überarbeiten Sie den Schwellenwert. Wenn Sie eventuelle Konsistenz akzeptieren, bevorzugen Sie Ereignisse, um die Kopplung zu reduzieren. Wenn der Consumer nur eine kleine Teilmenge von Daten aus einem anderen Kontext lesen muss, ist eine Shadow Entity möglicherweise sicherer als die Offenlegung der gesamten ursprünglichen Entität.