Architekturmuster

Erfahren Sie mehr über die gut durchdachte Ressourcen- und Kostenoptimierung → Ihre Optimierungsverantwortungen

Auf dieser Seite finden Sie eine umfassende Musteranleitung für architektonische Belange, einschließlich Funktionseinheiten, Trennung von Belangen, Statusverwaltung, API-Verwaltung und Messaging. Diese Muster prägen den langfristigen Lösungserfolg durch bewusste Designentscheidungen zu Servicegrenzen, Datenzugriffsmustern und Komponentenverantwortungen.

Muster

Wohin schauen	Wie gut aussieht
Apex Klassen	✅ Serviceklassen folgen dem Prinzip der Einzelverantwortung, wobei die Namen den Zweck eindeutig angeben (AccountService, OrderProcessor, InventoryManager). Jede Serviceklasse konzentriert sich auf eine Domäne oder Geschäftsfunktion. Methoden in Serviceklassen weisen einzelne, fokussierte Verantwortlichkeiten in 20 Zeilen auf.
Auslöser	✅ Auslöser werden an Handler-Klassen delegiert, statt direkt Geschäftslogik zu enthalten. Das Auslöser-Handler-Muster wird einheitlich mit eindeutigen Methodennamen nach Kontext verwendet (handleBeforeInsert, handleAfterUpdate). Handler-Klassen organisieren Logik nach Auslöserereignis mit einzelnen Verantwortlichkeiten pro Methode.
Lightning Web Components	✅ Komponenten folgen dem Prinzip der Einzelverantwortung mit klaren Requisitenoberflächen für die Konfiguration. Jedes LWC konzentriert sich auf ein Benutzeroberflächenanliegen (Datenanzeige, Benutzereingabe, Navigation). Komponenten, die für die Zusammensetzung konzipiert sind, nicht für monolithische Implementierungen.
Serviceebene	✅ Serviceklassen kapseln Geschäftslogik unabhängig vom Eintrittspunkt (Auslöser, API, Flow, Batch). Dieselbe Serviceklasse verarbeitet mehrere Aufrufkontexte ohne Duplikate. Serviceebene trennt Geschäftsregeln von Darstellungs- und Datenzugriffsproblemen.
Wiederverwendbare Komponenten	✅ Komponenten, die für die Wiederverwendung in mehreren Projekten und Teams konzipiert wurden. Konfigurationsgesteuertes Verhalten bei Verwendung benutzerdefinierter Metadatentypen ermöglicht Verhaltensänderungen ohne Codebereitstellung. Aufrufbare Aktionen stellen Apex Logik als deklarative Bausteine bereit, die über Flow und externe Orchestrierung verwendet werden können.

Antimuster

Wohin schauen	Wie schlecht sieht
Gottesklasse	⚠️ Vermeiden Sie übermäßige Verantwortung in einer einzelnen Klasse. Teilen Sie große Klassen (> 500 Zeilen) in fokussierte Klassen mit einzelnen Verantwortlichkeiten auf. Ordnen Sie Klassen neu an, wenn sie mehrere nicht verwandte Anliegen verarbeiten (OrderProcessor sollte nicht auch das Senden von E-Mails und Berichte verarbeiten).
Gemischte Bedenken	⚠️ Vermeiden Sie das Mischen von Auslöserlogik, Geschäftsregeln und Datenzugriff in einzelnen Klassen. Trennen Sie Präsentationslogik von Geschäftslogik in Steuerfeldern. Halten Sie Integrationsanliegen von der Kerndomänenlogik getrennt.
Auslöserlogik in Auslösern	⚠️ Vermeiden Sie es, Geschäftslogik direkt in Auslöserdateien einzubetten. Verwenden Sie niemals mehr als 300 Zeilenauslöser mit verschachtelten Bedingungen. Legen Sie die Delegierung immer an Handler-Klassen mit klarer Methodenorganisation nach Auslöserkontext fest.

Muster

Wohin schauen	Wie gut aussieht
Geschäftslogik	✅ Geschäftsregeln zentralisiert in Serviceklassen, nicht verstreut über Auslöser, Steuerfelder und Batchklassen. Domänenklassen kapseln das Verhalten auf Datensatzebene (Validierung, Standardwerte, abgeleitete Werte) einheitlich, unabhängig davon, wie Datensätze in das System gelangen. Logik, die über die Serviceebene wiederverwendet wird, statt sie über Eintrittspunkte hinweg zu duplizieren.
Datenzugriff	✅ Datenzugriff, der hinter Repository- oder Auswahlmusterklassen abstrahiert wird. SOQL-Abfragen, die in Auswahlklassen (AccountSelector, OpportunitySelector) zentralisiert sind, um konsistente Feldlisten und WHERE-Klauseln zu gewährleisten. Das Repository-Muster ermöglicht Tests mit simulierten Datenquellen, ohne die Geschäftslogik zu ändern.
Schnittstellenverträge	✅ Komponenten kommunizieren über explizite Schnittstellen und nicht über Implementierungsdetails. Apex Schnittstellen definieren Verträge zwischen Ebenen. Benutzerdefinierte Metadatenkonfiguration definiert Verhaltensgrenzen. Plattformereignisse stellen Messaging-Verträge zwischen Produzenten und Verbrauchern bereit.
Modulgrenzen	✅ Begrenzte Kontexte definieren klare Inhaberschaftsgrenzen für Datenmodelle und Geschäftsregeln. Jedes Modul besitzt seine Daten, Automatisierung und Geschäftslogik. Module interagieren über definierte APIs, statt Datenbankobjekte direkt freizugeben. In der Dokumentation wird eindeutig angegeben, welches Team Inhaber welcher Objekte und Services ist.
Abhängigkeits-Flow	✅ Abhängigkeiten fließen in eine Richtung (Darstellung → Geschäft → Daten). Die Kerngeschäftslogik hängt von nichts Externem ab, was eine unabhängige Entwicklung ermöglicht. Infrastrukturbelange (Protokollierung, Zwischenspeicherung, externe APIs) hängen von der Geschäftslogik über Schnittstellen ab, nicht umgekehrt.

Antimuster

Wohin schauen	Wie schlecht sieht
Logische Duplizierung	⚠️ Vermeiden Sie doppelte Geschäftslogik über Auslöser, API-Endpunkte und Batchklassen hinweg. Zentralisieren Sie die Funktion in der Serviceebene und verwenden Sie sie punktübergreifend wieder. Sobald dieselbe Geschäftsregel in mehreren Klassen angezeigt wird, können Sie sie in den freigegebenen Service extrahieren.
Datenzugriff gestreut	⚠️ Vermeiden Sie SOQL-Abfragen, die über Auslöser-, Steuerfeld- und Batchklassen mit inkonsistenten Feldlisten und WHERE-Klauseln verstreut sind. Zentralisieren Sie Abfragen in Auswahlklassen, um konsistente Muster zu gewährleisten und die LDV-Optimierung an einem Ort zu aktivieren.
Geschäftslogik in Auslösern	⚠️ Vermeiden Sie Validierungsregeln, Feldberechnungen und Workflow-Orchestrierung, die direkt in Auslösercode eingebettet sind. Wechseln Sie zu Serviceklassen oder Domänenklassen. Halten Sie Auslöser dünn und konzentrieren Sie sich nur auf die Delegierung an die entsprechenden Handler.
Geschäftslogik in Steuerfeldern	⚠️ Vermeiden Sie komplexe Berechnungen, Validierungen oder Datenmanipulationen in Aura/LWC-Steuerfeldmethoden. Steuerfelder sollten Aufrufe an die Serviceebene orchestrieren und keine Geschäftsregeln direkt implementieren.
Kreisabhängigkeiten	⚠️ Vermeiden Sie Pakete oder Klassen mit kreisförmigen Abhängigkeiten, bei denen A von B und B von A abhängt. Lösen Sie diese Lösung, indem Sie gemeinsame Anliegen in ein separates Modul extrahieren, die Abhängigkeitsrichtung umkehren oder die ereignisgesteuerte Kommunikation verwenden, um die Kopplung zu unterbrechen.

Muster

Wohin schauen	Wie gut aussieht
Plattform-Cache (Organisationspartition)	✅ Häufig aufgerufene Referenzdaten, die in der Organisationspartition zwischengespeichert werden, einschließlich benutzerdefinierter Metadaten-Nachschlagevorgänge, Auswahllistenwerte, Konfigurationseinstellungen und berechneter Ergebnisse teurer Vorgänge. Standardmäßige TTL, die anhand der Datenvolatilität konfiguriert wird (Stunden für monatlich wechselnde Referenzdaten, Minuten für häufig aktualisierte Konfigurationen). Die Cache-Schlüsselstrategie verhindert Kollisionen zwischen verschiedenen Datentypen.
Plattform-Cache (Sitzungspartition)	✅ Benutzerspezifische Voreinstellungen, berechnete Personalisierungsdaten und der im Sitzungs-Cache gespeicherte Status in Sitzungsform. Sitzungs-Cache, der nicht für Daten verwendet wird, die für Benutzer freigegeben werden sollten. Die Cache-Entwertungsstrategie verarbeitet Benutzervoreinstellungsaktualisierungen entsprechend.
Lightning Data Services	✅ LDS bietet automatische clientseitige Zwischenspeicherung von Datensätzen für Lightning Webkomponenten. Standardmäßige CRUD-Vorgänge verwenden LDS anstelle von benutzerdefinierten Apex-Steuerfeldern. LDS eliminiert redundante Serverrundfahrten und bietet optimistische Benutzeroberflächenaktualisierungen. Komponenten nutzen den freigegebenen LDS-Cache seitenübergreifend.
Benutzerdefinierte Metadatentypen	✅ Konfigurations- und Verhaltensregeln, die in benutzerdefinierten Metadatentypen gespeichert und nicht in Klassen hartcodiert sind. Benutzerdefinierte Metadaten, die über Änderungssets oder quellgesteuerte Entwicklung umgebungsübergreifend bereitgestellt werden können. Änderungen an benutzerdefinierten Metadaten erfordern keinen vollständigen Bereitstellungszyklus. Zwischenspeichern von benutzerdefinierten Metadatenabfragen im Plattform-Cache für die Leistung.

Antimuster

Wohin schauen	Wie schlecht sieht
Abfrage in Schleife	⚠️ Vermeiden Sie die Ausführung von SOQL in Iterationsschleifen. Fragen Sie alle erforderlichen Datensätze in einer einzelnen SOQL-Anweisung außerhalb von Schleifen ab. Organisieren Sie Ergebnisse in Maps nach übergeordneter ID, um sie während der Iteration nachzuschlagen. Dies ist das häufigste Salesforce-Antimuster.
Wiederkehrende Abfragen	⚠️ Vermeiden Sie es, dieselben benutzerdefinierten Metadaten, benutzerdefinierten Einstellungen oder Referenzdaten mehrmals pro Transaktion abzufragen. Einmal abfragen, im Plattform-Cache oder in der statischen Transaktionsvariablen zwischenspeichern, transaktionsübergreifend wiederverwenden.
Fehlende Cache-Strategie	⚠️ Vermeiden Sie es, häufig aufgerufene Referenzdaten ohne Zwischenspeicherung wiederholt abzufragen. Implementieren Sie den Plattform-Cache für benutzerdefinierte Metadaten, Konfigurationen und berechnete Ergebnisse. Definieren Sie die geeignete TTL anhand der Datenvolatilität.
Cache ohne Ungültigkeit	⚠️ Vermeiden Sie das Zwischenspeichern von Daten, ohne die Invalidierungsstrategie in Betracht zu ziehen. Definieren Sie die für die Aktualisierungshäufigkeit geeignete Cache-TL. Implementieren Sie die manuelle Cache-Löschung, wenn sich die Quelldaten ändern, wenn TTL allein nicht ausreicht.
Nicht verwalteter Sitzungsstatus	⚠️ Vermeiden Sie es, anzunehmen, dass der Sitzungsstatus über die Seitennavigationen hinweg unverändert bleibt. Lightning-Komponenten sollten die Statusaktualisierung beim Laden von Seiten verarbeiten. Verwenden Sie Lightning Data Service für die automatische Statussynchronisierung.

Muster

Wohin schauen	Wie gut aussieht
Lösungsarchitekturplanung	✅ Die Architekturplanung erfolgt vor bedeutenden Investitionen in den Bau, einschließlich der Anforderungsanalyse (funktional und nicht funktional), der Analyse der Obergrenzen für erwartete Datenvolumen, der an die Anforderungen angepassten Musterauswahl und des Komponentendesigns, das wichtige Komponenten und Schnittstellen definiert.
Auswahl des Designmusters	✅ Bewährte Salesforce-Designmuster werden einheitlich angewendet: Service Layer Pattern für die Wiederverwendung von Geschäftslogik, Repository/Selector Pattern für die Datenzugriffsabstraktion, Strategy Pattern für austauschbare Algorithmen, Domain Pattern für das Verhalten auf Datensatzebene, Trigger Handler Pattern für die konsistente Auslöserorganisation.
Architekturentscheidungsdatensätze	✅ Wichtige Architekturentscheidungen, die in in der Versionskontrolle gespeicherten ADRs dokumentiert sind. AS erfassen Kontext (Geschäftsfaktoren, technische Einschränkungen), Entscheidung (was ausgewählt wurde), berücksichtigte Alternativen (warum andere abgelehnt wurden) und Konsequenzen (Kontexte, technische Schulden, Auslöser für erneute Besuche).
Build vs Buy Evaluation (Erstellung vs. Kaufbewertung)	✅ Die AppExchange-Bewertung geht benutzerdefinierten Entwicklungsentscheidungen mit der Analyse der Gesamtbetriebskosten voraus. Zu den Bewertungskriterien zählen der strategische Wert (Wettbewerbsdifferenzierer im Vergleich zur Ware), der TCO-Vergleich (Erstellungsaufwand, Wartung, Upgrade-Kosten), die Integrationskomplexität und die Ausstiegskosten, wenn sich die Lösung als unzureichend erweist.
Analyse der Obergrenze für Gouverneure	✅ Die Architekturplanung identifiziert, welcher Regler das Design der meisten Einschränkungen bei erwarteten Datenvolumen und Transaktionsmustern einschränkt. Transaktionen, die so konzipiert sind, dass sie unter Spitzenbedingungen weniger als 80 % der einzelnen Obergrenzen ausschöpfen. Marge für Wachstum, künftige Funktionen und unerwartete Nutzungsmuster.
Risikobewertung	✅ Technische Risiken für architektonische Ansätze, die Plattformgrenzen überschreiten. Für jedes signifikante Risiko definierte Strategien zur Eindämmung. Bei Prototypen- oder Proof-of-Concept-Arbeiten werden Annahmen für technische Ansätze mit hohem Risiko vor dem vollständigen Build-Engagement validiert.

Antimuster

Wohin schauen	Wie schlecht sieht
Keine Planung	⚠️ Vermeiden Sie es, mit der Erstellung zu beginnen, ohne Datenvolumen, Auswirkungen auf die Obergrenze oder Musterauswahl zu analysieren. Der Architekturplanungsworkshop sollte wichtige Einschränkungen identifizieren, Muster auswählen und anhand von Obergrenzen validieren, bevor mit der Erstellung begonnen wird.
Nicht dokumentierte Entscheidungen	⚠️ Vermeiden Sie architektonische Entscheidungen, die in Besprechungen getroffen werden, ohne Kontext, Gründe, Alternativen und Konsequenzen zu erfassen. Verwenden Sie in der Versionskontrolle gespeicherte Architekturentscheidungsdatensätze, um den Entscheidungskontext für künftige Teammitglieder beizubehalten.
Keine Build- vs-Buy-Analyse	⚠️ Vermeiden Sie die Erstellung benutzerdefinierter Lösungen ohne AppExchange-Bewertung. Bewerten Sie die wichtigsten 3-5 relevanten Pakete vor der benutzerdefinierten Entwicklung. Vergleichen Sie die TCO einschließlich Implementierungsaufwand, Wartung, Upgrade-Kosten und Beendigungskosten.
Unteringenieurwesen	⚠️ Vermeiden Sie es, nur für aktuelle Datenvolumen ohne Wachstumsprognose zu entwerfen. Prognostizieren Sie ein Datenwachstum von 2-3 Jahren. Entwerfen Sie Abfragemuster mit einer Selektivität, die für 5-10x aktuelle Volumen validiert wurde. Bauen Sie architektonische Spielräume für Wachstum.

Muster

Wohin schauen	Wie gut aussieht
Verwaltete Pakete der zweiten Generation (2GP)	✅ 2GP für neue verwaltete Pakete, die Namespace-Isolation, AppExchange-Verteilung und Schutz des geistigen Eigentums erfordern. Quellgesteuerter Entwicklungs-Workflow mit modularer Anwendungsentwicklung. Paketabhängigkeiten, die explizit verwaltet werden. Versionen, die mit semantischer Versionierung veröffentlicht wurden.
Entsperrte Pakete	✅ Entsperrte Pakete, die für interne Unternehmensanwendungen verwendet werden, die Modularität ohne Namespace-Einschränkungen erfordern. Unabhängige Bereitstellung von Paketen ohne organisationsabhängige Artefakte. Paketabhängigkeiten werden für die ordnungsgemäße Bereitstellungsreihenfolge verfolgt. Versionierungsstrategie, die für interne Pakete definiert ist.
Modulgrenzen	✅ Klare Inhaberschaftsgrenzen, die für jedes Paket definiert sind. Jedes Paket besitzt sein Datenmodell, seine Geschäftsregeln und seine Automatisierung. Pakete interagieren über definierte Schnittstellen und nicht über direkten Objektzugriff. In der Dokumentation werden die Paketinhaberschaft und Verträge zwischen Paketen angegeben.