Komponentenansatz in der Software-Architektur

Komponentenbasierte Architektur: Vom Monolithen zu skalierbaren Systemen

Die komponentenbasierte Architektur behandelt Verzeichnisse wie Bausteine auf einem Diagramm und Abhängigkeiten wie Verbindungsleitungen. Jede Komponente ist ein Verzeichnis mit Code, das zu einer Bibliothek kompiliert wird. Abhängigkeiten werden vom Build-Tool verwaltet – etwa zieht crm/core die Module crm/api und payments/api hinzu, um eine Zahlungsgateway-Integration zu ermöglichen.

Dies schafft eine natürliche Verschachtelung, ähnlich wie in einem Dateisystem, und gewährleistet reibungslose Interoperabilität. Der Ansatz funktioniert mit jedem modernen Build-Tool und jeder Programmiersprache und skaliert von Monolithen bis hin zu Microservices.

API und SPI für Datenabstraktion

Trennen Sie die Kernlogik des Geschäfts von der Infrastruktur mit dem API-SPI-Muster. Die API ist der Vertrag, den Ihre App nach außen kommuniziert (z. B. eine CRM-Schnittstelle). Die SPI ist der Vertrag für externe Anbieter (PostgreSQL für Speicher, TigerBeetle für Zahlungen).

Wichtige Vorteile:

• Die Kernlogik bleibt unabhängig von spezifischen Datenbanken oder Diensten.
• Ersetzen Sie Implementierungen, ohne den Kern neu zu bauen.
• Unterstützen Sie mehrere Anbieter in einem einzigen Bootstrap-Prozess.

Das Diagramm platziert core zwischen api und spi, wobei Infrastrukturkomponenten die SPI umsetzen.

Bootstrap für die App-Zusammenstellung

Erstellen Sie eine Bootstrap-Komponente als Plug-and-Play-Abhängigkeit. Sie verbindet SPI-Implementierungen mit den APIs im Kontext der App. Moderne Frameworks lösen Abhängigkeiten automatisch; in einfachen Sprachen nutzen Sie die Build-Konfiguration.

Beispiel: Ein CRM-Bootstrap verbindet crm/core und payments/core über einen gemeinsamen Kontext. Das vereinfacht den Deployment-Prozess – fügen Sie einfach die Abhängigkeit hinzu, und los geht's.

Übergang zu Microservices

Für unabhängiges Skalieren zerlegen Sie den Monolithen:

• Extrahieren Sie eigenständige Apps für CRM und Zahlungen.
• Fügen Sie in CRM einen rest-client hinzu, der die Payments-API über HTTP umsetzt.
• In Zahlungen kommt ein rest-server, der über Bootstrap zu payments/core weiterleitet.
• Teilen Sie gängige DTOs in rest-common.
• Verpacken Sie den Client in CRMs Bootstrap.

Ergebnis: Ein Cluster mit klar abgegrenzten Kontexten, in dem Komponenten unabhängig skalieren.

Plattformkomponenten

Extrahieren Sie gemeinsame Lösungen in eine Plattform, um das DRY-Prinzip (Don't Repeat Yourself) einzuhalten:

• Konfigurationen für PostgreSQL und TigerBeetle.
• REST-Client/Server-Kommunikation.
• Authentifizierung, asynchrone/synchrone Messaging und Speicher.

Die Plattform reduziert Duplikate: Komponenten greifen auf fertige Setups zu. Skalieren Sie die Wiederverwendbarkeit von Basis- bis Enterprise-Lösungen.

Vorteile und Governance

Komponenten setzen klare Grenzen nach Conways Gesetz: Weisen Sie sie Teams zu und verfolgen Sie Interaktionen.

Lebenszyklus-Management: Kleine Komponenten lassen sich leicht austauschen und migrieren.

Bleiben Sie an Anforderungen ausgerichtet: Abstraktionen erlauben Stack-Wahlen basierend auf KPIs (Performance, Kosten), nicht auf Gewohnheiten.

Wann einsetzen?

Ab Tag eins: Von Prototypen bis zu verteilten Systemen. Funktioniert mit jedem Build-Tool, skaliert auf Repos und Teams. Vermeiden Sie den 'Big Ball of Mud' – Komponenten ermöglichen sanfte Evolution.

Wichtige Erkenntnisse:

• Granulare Verzeichnisse als Einheiten für Deployment und Verantwortung.
• API/SPI für Entkopplung von der Infrastruktur.
• Bootstrap für automatische Kontext-Zusammenstellung.
• Plattform für maximales DRY und Reuse.
• Nahtloser Übergang von Monolith zu Microservices ohne Kern-Refactoring.

— Editorial Team