Lesen Sie hier unsere Aktualisierungspläne.

Zusammensetzbare Lösungen passen sich schnell und stabiler an. Ein System, das für die Zusammenstellung konzipiert ist, wird in sinnvollen Einheiten oder Bausteinen erstellt, die graziös miteinander operieren und einfach ein- und ausgewechselt werden können. Durch die Integration der Zusammensetzbarkeit in ein System können Sie neue Funktionen einführen oder technische Schulden entfernen, indem Sie einzelne Einheiten eines Systems refaktorieren oder neu zusammenstellen. Die Composability ermöglicht schnellere, besser vorhersehbare Bereitstellungszyklen und -versionen, da sich Teams auf die Erstellung und Bereitstellung sinnvoller Funktionen mit geringeren Änderungsmengen konzentrieren können.

Mithilfe von Composable-Systemen können sich Unternehmen schneller und stabiler anpassen – unabhängig davon, ob der Stimulus unternehmensintern oder durch externe Faktoren verursacht wird. Durch die Zusammensetzbarkeit werden Systeme widerstandsfähiger und Lösungen und architektonische Muster können absichtlicher gestaltet werden.

Sie können Ihre Salesforce-Lösungen komfortabler gestalten, indem Sie drei wichtige Gewohnheiten entwickeln: Trennung von Bedenken, Interoperabilität und Paketierbarkeit. Unten sehen Sie die Beziehung dieser Gewohnheiten auf zwei Arten: für eine einzelne Einheit in einem zusammengesetzten System und für mehrere Einheiten in einem zusammengesetzten System.

Eine einzelne zusammensetzbare Einheit:

Ein zusammengesetztes System:

Die Trennung von Anliegen ist ein grundlegendes Konzept im Software Engineering und in der Systemarchitektur und beinhaltet die Identifizierung verschiedener Anliegen in einem größeren System, das in modulare Einheiten unterteilt werden kann. Um eine starke Trennung von Bedenken innerhalb eines Systems zu erreichen, müssen sinnvolle Einheiten für die Anwendungslogik und -funktionen im gesamten System erstellt werden. Kleinere Einheiten erleichtern es Anwendungszustellungs- und Wartungsteams, nachzuvollziehen, wie und wo Änderungen vorgenommen werden können, ohne dass das größere System unterbrochen wird. Kleinere Einheiten machen zudem deutlicher, wie und wo Sie sich bei der Bewältigung technischer Schulden auf die Arbeit konzentrieren sollten, und tragen zur allgemeinen Lesbarkeit Ihres Systems bei.

Sie können Ihre Salesforce-Organisation besser voneinander trennen, indem Sie sich an der Geschäftsfähigkeit orientieren und den Status verwalten.

Bei Salesforce-Systemen wendet der beste Ansatz zur Trennung von Bedenken eine geschäftsorientierte Perspektive an, um modulare Einheiten (oder Funktionen) im System zu identifizieren und zu organisieren. Dies ist im Gegensatz zu einer auf Technik ausgerichteten Ansicht, die Einheiten anhand ihrer technischen Funktion identifiziert. Eine geschäftsorientierte Perspektive zur Trennung von Bedenken erfordert die Organisation des Codes und der Anpassungen in Ihrem System anhand des Service, den sie für Geschäfts- und Geschäftsbenutzer bereitstellen. Dieser Ansatz bedeutet nicht, dass das Potenzial für redundante oder doppelte technische Funktionen in einem System ignoriert wird. Vielmehr bedeutet dies, dass technische Dienstleistungen eindeutig einem Organisationsprinzip zugeordnet sind, das für das Unternehmen letztlich transparent ist.

Durch die Ausrichtung auf Geschäftsfunktionen wird sichergestellt, dass die Übergabe zwischen Geschäftsanalyse- und Discovery-Teams an Bereitstellungsteams so einfach wie möglich ist. Wenn Anwendungsgeneratoren keine Ahnung haben, wo ihre Arbeitseinheiten in Ihrer zusammengesetzten Architektur zugeordnet sind, besteht ein Chaos und keine zusammengesetzte Anwendungslandschaft. Unklare Zuordnungen zwischen dem für das Unternehmen erforderlichen Endstatus und den modularen Einheiten in einer Organisation erhöhen zudem die Wahrscheinlichkeit, dass Entwicklungsteams oder -anbieter redundante Funktionen in das System integrieren.

Beachten Sie Folgendes, um Funktionseinheiten an der Geschäftsfähigkeit auszurichten:

• Beginnen Sie mit zu erledigenden Aufträgen. Konzentrieren Sie sich auf die zu erledigenden Aufgaben der Benutzer und das Unternehmen selbst. Der JTBD-Ansatz wurde von Tony Ulwick entwickelt und konzentriert sich auf das Verständnis des „Jobs“ oder des wahren Zwecks, den Menschen mit einem Produkt oder Service erreichen möchten. Es ist eine höhere Abstraktionsebene als die rollenbezogenen Aufgaben der Benutzer oder die einzelnen Schritte in einem Geschäftsprozess. Aufgaben wie Duplikatsprüfungen und Adressvalidierungen können beispielsweise in die übergeordnete Funktion "Einzelansicht des Kunden einrichten" fallen. Nachdem Sie einen klaren Eindruck von diesen übergeordneten Geschäftsfunktionen erhalten haben, können Sie beginnen, ihnen Teile Ihres Systems zuzuordnen.
• Orientieren Sie sich an Funktionen und nicht an Berichtsstrukturen. Die interne Hierarchie Ihrer Geschäftseinheiten ist kein Proxy für sinnvolle Funktionen oder zu erledigende Aufgaben. Die interne Hierarchie Ihres Unternehmens hat wesentliche Auswirkungen auf Prozesse und Teamstrukturen (ganz zu schweigen von Budgets). Das sind wichtige logistische Überlegungen. Aber die funktionalen Anforderungen des Unternehmens funktionieren auf einer höheren Abstraktionsebene als die Logistik. Wenn Sie ein Modul erstellen, um eine Berichtsstruktur anstelle einer übergeordneten Funktion bereitzustellen, sollten Sie beachten, dass Sie möglicherweise zusätzliche Schritte ausführen müssen, um zu ermitteln, wie sich dieses Modul auf die Geschäftsfunktionen bezieht.
• Seien Sie iterativ. Arbeiten Sie zunächst mit dem Unternehmen zusammen, um zu ermitteln, welche Funktionen für ein minimal lebensfähiges Produkt (MVP) funktionieren könnten. Wenn Sie eine Funktion identifizieren, erstellen Sie diesen MVP. Identifizieren Sie beim Erstellen die Prozesse, Metadaten und Ereignisse oder Nachrichten, die für die von Ihnen erstellte Funktionseinheit zentral sind. Identifizieren Sie alle Prozesse, Metadaten und Ereignisse oder Nachrichten, bei denen es sich um externe Abhängigkeiten handelt. Implementieren Sie die API-Verwaltung und die Abhängigkeitsverwaltung, um Einheiten zu erstellen, die gut miteinander funktionieren (anstatt isolierte Einheiten zu erstellen).

Die folgende Liste der Muster und Anti-Muster zeigt, wie eine ordnungsgemäße (und schlechte) Orientierung an Geschäftsfunktionen in einer Salesforce-Lösung aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu den von Salesforce verfügbaren Tools zur besseren Orientierung an den Geschäftsfunktionen finden Sie unter Tools Relevant to Composable (Für Composable relevante Tools).

Die Verwaltung des Bundesstaats konzentriert sich auf die Bewegung von Informationen in einem System zu verschiedenen Zeitpunkten. Durch eine effektive Statusverwaltung können Anwendungen komplexe Datenflüsse oder Interaktionen mit einem Minimum an ungeplanten oder unbestimmten Ergebnissen verarbeiten. Die Verwaltung des Status in einer modularen Salesforce-Organisation bedeutet, klare Pfade für Logik-Flows innerhalb und zwischen Einheiten sowie anmutige Pfade für ungeplantes Ausführungsverhalten zu erstellen. Mit der Statusverwaltung können kohärente Logikströme aus modularen Salesforce-Anwendungseinheiten gebildet werden. In den meisten Fällen erfordert dies eine Interoperabilität, um den Informationsfluss zwischen Einheiten zu strukturieren.

Schwierigkeiten bei der Verwaltung des Status über lose gekoppelte Einheiten hinweg führen häufig zu einer monolithischen Anwendungsentwicklung in Salesforce. Sie können dies in großen "Monoflows" sehen, die in dem Versuch erstellt wurden, einen komplexen Prozess innerhalb eines einzelnen Flows zu orchestrieren. Ein weiteres Beispiel sind massive Apex Klassen, die komplexe Prozesse über Spaghetti Code orchestrieren, oder eine lange Reihe von Single-Use Methoden. Diese Arten von Anwendungsarchitekturen erschweren das Refaktorisieren und Debuggen und erhöhen die Einarbeitungszeiten für neue Teammitglieder oder -anbieter. Sie verringern auch den Wert der Anwendungen, die an das Unternehmen bereitgestellt werden, da die Funktionen nicht wiederverwendet werden können.

Beachten Sie Folgendes, um den Status in einer modularen Salesforce-Organisation zu verwalten:

• Entscheiden Sie, wann zustandsbasierte und wann zustandslose Muster verwendet werden sollen. Bundesstaatliche Muster speichern Informationen über einen Ausführungspfad hinweg, zustandslose Muster hingegen nicht. In einem lose gekoppelten System ermöglichen zustandslose Muster eine schnellere und nebenwirkungsärmere Refaktorisierung von Komponenten. Statuslose Muster sind jedoch nicht für alle Anwendungsfälle geeignet. Wenn Sie Komponenten für Datenvorgänge erstellen, können Stateful Patterns die Datenintegrität und Konsistenz in Ihren Systemen verbessern. Verwenden Sie ein Bundesstaatsmuster, wenn Ihre Komponente eines der folgenden Kriterien erfüllt:
  • Die Kenntnis der Platzierung innerhalb eines größeren Ausführungspfads ist für das Verhalten der Komponente entscheidend
  • Das Verhalten der Komponente muss sich basierend auf den Ergebnissen einer nachgelagerten Aktion ändern (beispielsweise muss sie die Ausführung basierend auf Rollback-/Fehler-/Erfolgsmeldungen aus nachgelagerten Komponenten ändern).
  • Die Komponente muss auf Antworten von einem externen oder nachgelagerten System warten, um ihre Arbeit abzuschließen.
• Erstellen Sie aussagekräftige Kategorien für aussagekräftige Informationen. Status ist ein mehrdeutiger Begriff, der auf eine so umfassende und breite Palette von Informationen innerhalb (und darüber hinaus) einer Salesforce-Organisation angewendet werden kann, dass er für sich genommen fast bedeutungslos ist. Ein notwendiger erster Schritt zum Erstellen von zustandsbasierten Mustern besteht daher darin, sinnvolle Kategorien für die wichtigsten zustandsbasierten Ausführungspfade (oder Arten von zustandsbasierten Verhaltensweisen) in Ihrem System zu erstellen. Einige zu berücksichtigende Kategorien:
  • Navigation und Formulare
  • Datenbankvorgänge
  • Batch- und Massenvorgänge
  • Fehler
• Definieren Sie datenbezogene Status in Form von Datenbanktransaktionen. Die integrierten Verhaltensweisen der Plattform werden die meisten Überlegungen zu den Bundesstaaten für Daten in Salesforce umschreiben. Versuchen Sie nicht, dieses Verhalten zu umgehen. Design für und mit ihm. Entwerfen Sie Lösungen, die die Logik verteilter Transaktionen minimieren oder eliminieren. (Weitere Details finden Sie unter Datenverarbeitung).
• Identifizieren Sie Status, die innerhalb (und übergreifend) von Funktionseinheiten auftreten. Achten Sie beim Zusammenstellen von Funktionseinheiten in größeren Systemen darauf, wann Sie das Verhalten von zustandslosen und zustandsbasierten Komponenten mischen, und verhindern Sie Kombinationen, die zu Endlosschleifen oder Lücken in der Verarbeitung führen könnten.
• Definieren Sie Übergaben. Überlegen Sie, welche Messaging- oder Ereignismuster Komponenten verwenden, um zustandsbezogene Daten an einen anderen Teil des Systems zu übertragen. Stellen Sie sicher, dass Sie Transaktionsbewusstsein aufbauen und Ihre Komponenten verarbeiten. Fügen Sie keine verteilte Transaktionslogik in Ihre Übergaben ein.
• Erstellen Sie Zuordnungen zwischen Ihren Prozessdiagrammen und -status. Prozessdiagramme enthalten Details zu den Schritten, mit denen Informationen zu verschiedenen Zeitpunkten durch Ihr System geleitet werden. In einem Zustandsdiagramm werden die tatsächlichen Änderungen der Informationen (der Status) angezeigt. Verwenden Sie den Abschnitt "Metadatenfußzeile" der Salesforce-Diagrammformen, um den sich ändernden Status der Informationen in jedem Schritt Ihres Prozesses zu erfassen. Wenn Sie Prozessdiagramme und Statusdiagramme trennen, verknüpfen Sie sie. Dieses Konzept sollte nicht mit der Erfassung des aktuellen und zukünftigen Zustands von Prozessen oder Systemlandschaften während des Entwurfs und der Implementierung verwechselt werden, da es nicht um die Informationen geht, die durch das System fließen.

In der folgenden Liste der Muster und Anti-Muster wird gezeigt, wie eine ordnungsgemäße (und schlechte) Zustandsverwaltung in einer Salesforce-Lösung aussieht. Sie können sie verwenden, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für die Statusverwaltung finden Sie unter Tools Relevant to Composable (Für Composable relevante Tools).

In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster zur Trennung von Bedenken im Explorer für Muster und Anti-Muster.

In einem auf Interoperabilität ausgelegten System können Komponenten Informationen austauschen und effektiv zusammenarbeiten. Interoperabilität ist ein Schlüssel, um ein modulares System zusammengesetzt und nicht isoliert zu gestalten. Die Interoperabilität kann in einem lose gekoppelten System schwierig zu erreichen sein. Sie müssen Standards für konsistente Integrationsmethoden festlegen, die die Unabhängigkeit zwischen Einheiten und die allgemeine Trennung von Bedenken im gesamten System nicht untergraben.

Die Interoperabilität wirkt sich auch auf die Qualität Ihrer Benutzererfahrungen aus. Ihre Benutzer erwarten, dass in einem Bereich erstellte Daten (wie Auftragsinformationen) in einem anderen Bereich (wie Marketingkampagnen) verwendet werden können, und Ihre Ersteller erwarten, dass sie, wenn sie etwas lernen (wie das Erstellen eines Flows oder die Authentifizierung bei einer API), feststellen, dass vertraute Techniken funktionieren, wenn sie zum nächsten Problem übergehen. Wenn die Interoperabilität nicht ausgelegt wird, führt dies zu redundanten Architekturen, replizierten Daten, Prozessineffizienzen und höheren Entwicklungs- und Supportkosten.

Sie können Interoperabilität in modularen Systemen mit Messaging und Eventing sowie mit der API-Verwaltung herstellen.

Nachrichten und Ereignisse sind zwei Möglichkeiten, mit denen Sie Komponenten in einem System das Senden und Empfangen von Informationen ermöglichen können. In Bezug auf die Inhalte, die sie übertragen können, ähneln sich Ereignisse und Nachrichten. Ein wesentlicher Unterschied besteht im Verhalten des Absenders. Eine Komponente, die eine Nachricht sendet, sendet in der Regel Daten an ein bestimmtes Ziel und wartet auf eine Antwort des Empfängers. Im Gegensatz dazu sendet eine Komponente ein Ereignis, wenn etwas passiert ist. Es gibt weder ein bestimmtes Ziel noch eine Antwort. Diese Verhaltensunterschiede unterstützen unterschiedliche Kommunikationsmuster. Nachrichten unterstützen zustandsbasierte Kommunikationsmuster und Ereignisse unterstützen zustandslose Kommunikationsmuster. (Weitere Informationen zu dieser Unterscheidung finden Sie unter Statusverwaltung.)

Es ist wichtig, Teams auf Protokolle und Anwendungsfälle für Messaging und Eventing abzustimmen. Unklare Standards können zu einer Mischung von Mustern in Ihrem System führen, was zu Folgendem führt:

• Leistungs- und Skalierbarkeitsprobleme, bei denen die falschen Muster auf einen bestimmten Anwendungsfall angewendet werden
• Inkonsistente Verarbeitung, die das System für Endbenutzer instabil erscheinen lässt
• Längere Fehlerbehebungszeiten und komplexere Wartungsprozesse

Beachten Sie beim Entwerfen von Nachrichten und Ereignissen Folgendes, um losere gekoppelte Strukturen in Ihrer Salesforce-Organisation zu erstellen:

• Identifizieren Sie synchrone und asynchrone Anwendungsfälle. Eventing ermöglicht lose gekoppelte, zustandslose und asynchrone Kommunikation über ein System hinweg. Messaging ermöglicht strenger gesteuerte, zustandsgesteuerte und synchrone Kommunikationsmuster. Wenn Sie entscheiden, wann Nachrichten oder Ereignisse verwendet werden sollen, müssen Sie entscheiden, ob Ihre Kommunikation synchron (und potenziell blockiert) und nicht asynchron und nicht blockiert sein soll.
• Definieren Sie Datenstrukturen sorgfältig. Die Struktur der Informationen, die Komponenten zwischen ihnen übertragen, ist ein wichtiger Teil, um ein lose gekoppeltes System überschaubar und kohärent zu halten. (Weitere Informationen finden Sie unter API-Verwaltung.) Eine wichtige Überlegung beim Entwerfen einer Nachricht oder eines Ereignisses ist, wie oft sich die Struktur der Informationen ändern muss. Sobald eine Nachricht oder Ereignisstruktur in Ihrem System definiert und implementiert ist, kann es schwierig sein, Aktualisierungen zu verarbeiten, insbesondere wenn das Ereignis oder die Nachricht bereits zum Senden von Informationen an ein externes System verwendet wird.
• Meldungen in richtiger Größe. Im Allgemeinen empfiehlt es sich, die Nachrichtengrößen klein zu halten. Es gibt jedoch auch einen Balanceakt zwischen der Größe der Nachricht und dem Volumen der Nachricht. Systeme können kleinere Datenmengen schneller verarbeiten. Der Verarbeitungsvorgang ist mit einem zusätzlichen Mehraufwand verbunden, da Empfänger Informationen entpacken, interpretieren und bestimmen müssen, was mit ihnen geschehen soll. Die Durchführung dieser Schritte kann vernachlässigbar viel Zeit in Anspruch nehmen, sie können sich jedoch aufbauen und eine Belastung für Systeme im großen Umfang verursachen. Vermeiden Sie Designs, bei denen Komponenten im System viele kleine Nachrichten nacheinander verarbeiten müssen, um eine Arbeit zu erledigen. Wenn Sie die richtige Größe Ihrer Nachrichten festlegen möchten, sollten Sie darüber nachdenken, die nachgelagerten Komponenten so zu gestalten, dass sie die gesendeten Informationen nur auf ein Minimum verarbeiten können, ohne auch nur davon auszugehen, dass jede nachgelagerte Komponente in der Lage ist, zahlreiche Folgenachrichten anzufordern oder zu verarbeiten.
• Design für Skalierbarkeit. Durch lose gekoppelte Komponenten kann Ihre Architektur einfacher skaliert werden. Durch die Eliminierung komponentenübergreifender Abhängigkeiten können Teams an der Verbesserung der Leistung oder Skalierbarkeit einer einzelnen Komponente mit minimalen Auswirkungen auf die anderen arbeiten. Locker gekoppelte Komponenten führen jedoch auch zu einer erheblichen Komplexität in Ihrer Architektur (insbesondere in Bezug auf den Verwaltungsstatus). Identifizieren Sie Prozesse, die aus gültigen Gründen der Benutzererfahrung oder aus Gründen der Datenintegrität enger mit Logik oder Abhängigkeiten verknüpft sein müssen, und versuchen Sie nicht, asynchrone/ereignisbasierte Muster in diese Prozesse einzuführen. Verwenden Sie stattdessen synchronisierungs-/meldungsbasierte Muster und eine ordnungsgemäße Fehlerbehandlung.

Die folgende Liste der Muster und Anti-Muster zeigt, wie richtiges (und schlechtes) Messaging und Eventing in einer Salesforce-Lösung aussehen. Sie können sie verwenden, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Messaging- und Eventing-Tools finden Sie unter Tools Relevant to Composable (Für Composable relevante Tools). Weitere Informationen zur Auswahl eines Eventing-Musters oder -Tools für einen bestimmten Anwendungsfall finden Sie im Architektenhandbuch zur ereignisgesteuerten Architektur mit Salesforce.

Durch das Erstellen einer ordnungsgemäßen Verwaltung der Anwendungsprogrammierschnittstelle (API) in einer Salesforce-Lösung können einzelne Komponenten Ihres Systems vorhersehbaren Kommunikationsmustern folgen. Salesforce bietet integrierte, sichere APIs für die Kommunikation mit Systemen außerhalb von Salesforce. (Weitere Informationen zu Salesforce Platform-APIs finden Sie unter Architekturgrundlagen.)

Eine effektive API-Verwaltung innerhalb von Salesforce-Lösungen ist der Schlüssel zum Erstellen wirklich komposibler Architekturen. Dadurch können Komponenten in einer Salesforce-Organisation Informationen effizient senden und empfangen. Außerdem können Lösungsentwickler klare Protokolle für die Kommunikation der von ihnen erstellten Komponenten mit anderen Komponenten im System befolgen und schlechte Implementierungen frühzeitig erkennen. Darüber hinaus können sich Lösungsentwickler enger auf die jeweilige Komponente konzentrieren, die sie erstellen oder refaktorieren, was die Produktivität und Qualität steigert.

Die API-Verwaltung auf Unternehmensebene ist ein separates Thema und lässt sich am besten mit einem umfassenden API-Verwaltungstool erreichen. (Weitere Informationen zur MuleSoft-Perspektive zu diesem Thema finden Sie unter Was ist API-Verwaltung?.)

Beachten Sie Folgendes, um API-Verwaltungsfunktionen in Ihren Salesforce-Lösungen zu erstellen:

• Stellen Sie sich APIs als vorhersehbare Muster oder Verträge für die Kommunikation vor. Der Datentyp der Eingabe- oder Ausgabevariablen, Variablennamen und die Informationen, die in einem bestimmten Muster angezeigt werden sollen (oder nicht), sind die Schlüssel für eine effektive API-Verwaltung. Diese Definitionen sollten in Ihren Designstandards angezeigt werden und Teams sollten in der Lage sein, über Ihre Dokumentation herauszufinden, wie diese Definitionen in bestimmten Teilen Ihres Systems implementiert wurden. Eine Möglichkeit, Schwierigkeiten beim Zusammenführen von Änderungen aus einer neuen Entwicklung in eine Integrationsumgebung anzuzeigen, besteht darin, sie als Beleg dafür zu betrachten, wo Sie die API-Kommunikation schlecht implementiert haben (oder möglicherweise gar keine API-Definition).

• Beschränken Sie Ihre Überlegungen zu APIs nicht nur auf Code. Was eine API in diesem Kontext definiert, ist die Konsistenz der Nachrichtenstrukturen und Variablen in dieser Nachricht. Solange diese Konsistenz gewahrt bleibt, kann eine API sowohl in Code als auch in deklarative Anpassungen implementiert werden, beispielsweise in modularen automatisch gestarteten (oder durch Plattformereignisse ausgelösten) Flows oder sogar in Flow-Vorlagen. Legen Sie bei Ihren Entscheidungen nicht die API-Implementierung zugrunde, sondern die Paketfähigkeit und Testbarkeit.

• Halten Sie Ihren Lebenszyklus und Ihre Versionierung einfach. Wie alle Teile der Anwendungsentwicklung haben APIs einen Lebenszyklus: Definieren, Erstellen, Testen, Bereitstellen und Verwalten (einschließlich Außerbetriebnehmen). Salesforce Platform-APIs veröffentlichen aufgrund des schnellen Versionszyklus der Plattform mehrere Versionen innerhalb eines Kalenderjahres. (Weitere Informationen zu diesem Verhalten finden Sie unter Salesforce Architecture Basics.) Das bedeutet, dass Plattform-APIs einen relativ komplexen Lebenszyklus aufweisen, da mehrere Versionen einer bestimmten API gewartet werden müssen und für Salesforce-Kunden verfügbar sein müssen. Dieser Komplexitätsgrad ist für PaaS-Anwendungsfälle angemessen, es handelt sich jedoch höchstwahrscheinlich um unnötige Komplexität für Ihre On-Platform-Lösungsarchitekturen (siehe: Lesbarkeitsantimuster). Konzentrieren Sie sich auf die Definition eines klaren Zwecks für eine API (z. B. Fehlerbehandlung) und klare Basisdefinitionen. Ziel ist es, nur über eine Version jeder API zu verfügen.

• Machen Sie Ihre APIs auffindbar, zugänglich und verwaltbar. Dokumentieren Sie Ihre APIs, damit potenzielle Verbraucher ohne Weiteres die verfügbaren APIs finden, die mit ihnen verbunden sind. APIs müssen als Teil einer Funktionslandschaft reibungslos funktionieren.

• Seien Sie iterativ. Konzentrieren Sie sich darauf, jeweils nur eine interne API zu definieren und zu implementieren. Auf diese Weise können Sie sich darauf konzentrieren, die API-Definition schnell zu wiederholen, das richtige Formular für Ihre eine unterstützte Version zu finden und bewährte Vorgehensweisen aus der Implementierungserfahrung zu erstellen.

Die folgende Liste der Muster und Anti-Muster zeigt, wie eine ordnungsgemäße (und schlechte) API-Verwaltung in einer Salesforce-Lösung aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu den von Salesforce verfügbaren Tools, mit denen Sie mehr Interoperabilität aufbauen können, finden Sie unter Für Composable relevante Tools.

In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster für die Interoperabilität im Explorer für Muster und Anti-Muster.

Durch das Erstellen der Paketierbarkeit in einer Salesforce-Organisation werden Funktionen in der Organisation aus Einheiten bereitgestellt, die unabhängig und zuverlässig als Pakete entwickelt und bereitgestellt werden können. Idealerweise sind diese Einheiten als Pakettyp der zweiten Generation definiert (entweder als entsperrtes Paket oder als verwaltetes Paket für ISVs). Hinweis: Da gut konzipierte Lösungen ausschließlich diese Pakettypen verwenden, werden verwaltete Pakete der ersten Generation hier nicht abgedeckt.

Es ist eine Sache, Bedenkentrennungen zu definieren und Funktionseinheiten in einer Salesforce-Organisation zu erstellen. Es ist eine weitere Sache, Abhängigkeiten klar genug zu entwirren und zu verwalten, um diese Einheiten erfolgreich als Paketartefakte zu versionieren. Um diesen Grad an Stabilität und Metadatenisolation zu erreichen, ist ein erheblicher Grad an DevOps (und Architektur) erforderlich. Darüber hinaus wird die Entwicklungszeit beschleunigt, die Erfahrung im Anwendungsgenerator verbessert und die Vorhersagbarkeit und Kontrolle der Versionen und der Versionsverwaltung verbessert. Nicht jede Organisation kann die Infrastruktur unterstützen, die zum Definieren, Verwalten und Entwickeln effektiver Pakete erforderlich ist. Die Paketierbarkeit sollte jedoch für fast jede Salesforce-Organisation das oberste Ziel sein.

Sie können die Paketierbarkeit in Ihren Salesforce-Lösungen erstellen, indem Sie sich auf die lose Kopplung und die Abhängigkeitsverwaltung konzentrieren.

Bei einem System mit loser Kopplung sind Einzelstücke nicht fest miteinander verbunden. Viele Vorteile eines zusammengesetzten Systems ergeben sich aus der losen Kopplung. In paketfähigen Systemen können Sie durch die lose Kopplung zwischen Paketen (und die Installation von Organisationen) über gut definierte Pakete und produktivere Entwicklungszyklen für Teams verfügen, die mit Paketen arbeiten.

Auf der Salesforce Platform können Sie Pakete erstellen, die eng mit einer bestimmten Organisation verknüpft sind. Diese Funktion ist nützlich, um Funktionseinheiten zu definieren und mit der richtigen Trennung von Bedenken in Ihrer Organisation zu experimentieren, während Sie die Paketerstellung vorantreiben. Wenn Sie sich für diesen Ansatz entscheiden, werden Sie jedoch einige der Vorteile wirklich paketfähiger Metadaten erkennen, einschließlich der quellgesteuerten Entwicklung, der Möglichkeit der Versionierung und der Artefaktstabilität. Stattdessen werden Sie wahrscheinlich weiterhin die Nachteile eines eng gekoppelten Systems erleben, einschließlich:

• Einzelne Fehlerpunkte, die zu Ausfällen und Leistungsproblemen führen
• Langsame, unvorhersehbare Bereitstellungen
• Schwierige, komplexe Debugging- und Fehlerbehebungszyklen
• Probleme mit Skalierung und Leistung

Das Endziel für jedes paketfähige Salesforce-System sind lose gekoppelte Pakete.

Beachten Sie beim Trennen Ihrer Salesforce-Metadaten in effektive Pakete Folgendes:

• Welche Anpassungen sind Daten im Vergleich zu Metadaten? In Bezug auf die Paketierbarkeit behandelt Salesforce Platform Daten und Metadaten sehr unterschiedlich. Es ist wichtig zu verstehen, welche Funktionen in Ihrer Organisation Metadaten oder Daten sind. Sie können keine Daten in Paketeinheiten aufnehmen. Wenn Sie entscheiden, wo Sie mit der Abstraktion von Funktionen in einer Paketeinheit beginnen möchten, müssen Ihre Teams entscheiden, ob als Daten gespeicherte Anpassungen vollständig aus dem Paket ausgeschlossen oder in eine metadatenbasierte Implementierung refaktoriert werden sollen.
• Wie sich die Paketerstellung auf Teams auswirkt. Eine logistische Realität der Salesforce-Paketerstellung besteht darin, dass für die Erstellung und Veröffentlichung einer Paketversion viel Geschick mit der Salesforce CLI und/oder der CI/CD-Technologie erforderlich ist. Das bedeutet, dass sowohl Low-Code- als auch programmgesteuerte Anpassungen Zeit und Aufmerksamkeit von jemandem erfordern, der in der Lage ist, mit paketbezogener DevOps-Technologie zu arbeiten. Je nachdem, wie Ihr Team die Funktionszustellung verwaltet, kann die Paketakzeptanz zu erheblichen Verzögerungen oder Blockaden für verschiedene Teams in einer Organisation führen. Sie müssen ermitteln, ob Teams die Funktionszustellung über die Paketerstellung verwalten können, und einen Plan erstellen, um Fertigkeits- oder Personallücken zu schließen. Zu den Lösungen zählen beispielsweise die Übernahme der Paarprogrammierung oder die Implementierung von CI/CD-Aufträgen für Entwicklungsumgebungen.
• Wie Paketerstellung Umweltstrategien verändern wird. In einem paketgesteuerten Entwicklungslebenszyklus sollte in Kratzorganisationen frühzeitig gearbeitet werden. Diese temporären, quellgesteuerten Entwicklungsumgebungen ermöglichen schnellere, iterativere Zyklen. Außerdem unterstützen sie genauere Zugriffssteuerungen für Umgebungen für Ihre Entwicklungsteams und eine bessere Isolation von der Produktion. Je mehr Abhängigkeiten Ihre Pakete von nicht im Paket enthaltenen Metadaten oder Daten aufweisen, die nur in einer Sandbox- oder Produktionsumgebung vorhanden sind, desto unwahrscheinlicher ist es, dass Teams Testorganisationen tatsächlich verwenden können. Sie können die Quellverfolgung in Sandbox-Instanzen aktivieren, um quellgesteuerte Entwicklungsmuster in Umgebungen zu ermöglichen, in denen es nicht um Testorganisationen geht. Ihre Entwicklungsteams profitieren jedoch nicht von der Geschwindigkeit und Iterationsgeschwindigkeit von Testorganisationen.
• Beziehung von Paketversionen zu Versionen. Planen Sie, wie oft und in welcher Phase die Versionierung von Entwicklungspaketen erfolgen soll. Paketversionsanforderungen sind (pro Organisation) auf einer rollierenden 24-Stunden-Basis begrenzt. Als allgemeine bewährte Vorgehensweise sollten Sie ein Paket nur dann als Version verwenden, wenn Sie sicher sind, dass sich keiner der Paketinhalte ändern muss. Idealerweise stellen Sie Paketversionen nach Abschluss der Qualitätssicherungsprozesse bereit. Lassen Sie nicht zu, dass Entwicklungsteams den Erfolg oder Misserfolg von Paketerstellungsanforderungen als "Tests" dafür verwenden, wie gut sie Paketgrenzen definiert haben. Es gibt Möglichkeiten, dies zu tun, ohne zu versuchen, ein Paketartefakt zu versionieren.
• Was der ideale Endzustand unterstützen sollte. Die ideale Paketerstellungsstrategie ermöglicht kontrollierte, stabile Salesforce-Versionen, die schnell entwickelt und bereitgestellt werden können. Wenn Sie zu viele Pakete in Ihrer gesamten Organisation definieren, kann dies zu neuen Komplexitäten und Engpässen für Entwicklungsteams führen. Eine zu modularisierte Organisation kann auch dazu führen, dass die Versionen langsam und schwierig sind. Beginnen Sie mit dem Erstellen und Veröffentlichen einiger Versionen eines einzelnen, aussagekräftigen Pakets. Leiten Sie Folgepakete inkrementell ab. Stellen Sie die Einführung von Paketen ein, wenn Sie über einen Versionsrhythmus verfügen, der Ihrem Unternehmen gut dient. Faktorpakete im Laufe der Zeit, wenn sich die Geschäftsanforderungen ändern oder die Versionsqualität sinkt. Der ideale Paketendzustand ist subjektiv.

Unabhängig davon, wie Sie Ihre Pakete definieren, werden Sie ein lose gekoppeltes Paket nur durch effektive Abhängigkeitsverwaltung erfolgreich versionieren.

Die folgende Liste der Muster und Anti-Muster zeigt, wie die ordnungsgemäße (und schlechte) lose Kopplung für Salesforce-Pakete aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools, mit denen Sie mehr Paketierbarkeit erstellen können, finden Sie unter Tools Relevant to Composable (Für Composable relevante Tools).

Im Kontext einer Salesforce-Lösung bedeutet Abhängigkeitsverwaltung, die Beziehungen zwischen den Metadaten in Ihren Paketen und den Metadaten in den Organisationen zu identifizieren und zu strukturieren, in denen diese Pakete installiert werden. Die Abhängigkeitsverwaltung ist ein wichtiger Bestandteil der Entwicklung stabiler Paketartefakte.

Abhängigkeiten stehen möglicherweise im Widerspruch zu Bemühungen, perfekt getrennte, lose gekoppelte Funktionseinheiten zu erstellen. Im idealen Engineering-Zustand weist ein lose gekoppeltes System keine Abhängigkeiten zwischen Einheiten auf. In der realen Welt ist es jedoch nicht sinnvoll, alle Abhängigkeiten zu beseitigen.

Oftmals erfordert die Balance zwischen der Lesbarkeit von Systemen und der Verwendung geschäftsfreundlicher Funktionseinheiten einen Kompromiss in Bezug auf eine perfekte Isolierung zwischen den Einheiten in einem System. Pragmatischer ausgedrückt: Die von der Standardfunktionalität der Salesforce Platform bereitgestellten Kernservices schaffen wichtige nettopositive Abhängigkeiten für jede Salesforce-Lösung. Viele integrierte Skalierbarkeits-, Leistungs- und Sicherheitsvorteile ergeben sich daraus, wie tief sie in die Plattform integriert sind. Beim Entwerfen von paketfähigen Salesforce-Lösungen sollten Sie beachten, dass Paketabhängigkeiten nicht von Natur aus schlecht sind. Schlechte Abhängigkeitsverwaltung ist schlecht.

Eine effektive Abhängigkeitsverwaltung mit Salesforce-Paketerstellung bedeutet, dass Entwicklungs- und Wartungsteams folgende Möglichkeiten haben:

• Schnelleres Onboarding in neue Projekte und eingeschränkter Umgebungszugriff
• Schnelles Entwickeln und Testen von Änderungen
• Verstehen, wie komplexe Funktionen in kleineren, spezifischen Verpflichtungen bereitgestellt werden sollten
• Steuern von Versionsrhythmen und Reduzieren von Systemwartungs-/Versionsausfallfenstern
• Prognostizierbares Wiederherstellen negativer Änderungen in jeder Umgebung

Die Techniken für die Abhängigkeitsverwaltung mit Salesforce sind ziemlich einfach:

• Verwenden Sie Messaging und Eventing, um anmutige Übergaben von zustandsbasierten oder zustandslosen Informationen zwischen Komponenten zu verarbeiten.
• Verwenden Sie benutzerdefinierte Metadatentypen, um dynamische Laufzeitinformationen bereitzustellen und Abhängigkeitsinjektionsmuster zu unterstützen.
• Lassen Sie Apex Entwickler abstrakte oder virtuelle Klassen verwenden.

Am Ende müssen Sie entscheiden, welche Designmuster in Ihrer Organisation bei der deklarativen und programmgesteuerten Entwicklung zulässig sind. Die wichtigsten Überlegungen (architektonisch) sind, zu definieren, wo Sie mehr technische Komplexität hinzufügen möchten, um weniger Abhängigkeiten zu haben, und wo Sie mehr Abhängigkeiten tolerieren müssen, um Workflows im Anwendungsgenerator zu vereinfachen.

Beachten Sie beim Erstellen von Abhängigkeitsverwaltungsstrategien in Ihren Paketen die beiden primären Organisationsprinzipien für Paketeinheiten: horizontal und vertikal.

• Horizontale Grenzen. In horizontalen Paradigmen werden Funktionen, die von mehreren Paketen benötigt werden, in eine horizontale Ebene abstrahiert. Horizontale Ebenen werden dann zur Quelle allgemeiner Funktionen und der Zugriff erfolgt über eine deklarierte Abhängigkeit. Die Minimierung redundanter Funktionen über Pakete hinweg wird der Minimierung von Abhängigkeiten vorgezogen.
• Vertikale Grenzen. Vertikale Paradigmen maximieren die Isolation und lockere Kopplung zwischen Teilen des Systems. Die freigegebenen Funktionen sind eingeschränkt und ähnliche Arbeiten werden möglicherweise einheitenübergreifend angezeigt. Abhängigkeiten sind streng begrenzt, um die Isolation zwischen Paketeinheiten zu maximieren.

Beachten Sie, dass dies keine Entweder-oder-Entscheidung ist. Sie können vertikale und horizontale Paradigmen nach Bedarf kombinieren. Häufig besteht der schnellste Weg, mit einem Paket zu beginnen, darin, horizontale Serviceebenen zu erstellen. Wenn die Skalierung und Komplexität Ihrer Paketakzeptanz wächst, können Sie durch Abstraktion weiterer vertikaler Einheiten Setup-Prozesse für komplexe Umgebungen oder die Einarbeitung von Entwicklern vereinfachen.

Beispielsweise kann ein System mit zwei Funktionseinheiten (A und B) mit Paketabhängigkeiten strukturiert werden, die in vertikalen, horizontalen und vertikal-horizontalen Hybridparadigmen angeordnet sind.

Unabhängig vom Organisationsparadigma des Pakets, das Sie auswählen, sollten Sie einige Absolutwerte beachten:

• Duplizieren Sie Metadaten nicht paketübergreifend. Metadaten, die von mehreren Paketen benötigt werden, sollten in ein oder mehrere Pakete abstrahiert werden, die als Abhängigkeiten deklariert sind.
• Nutzen Sie die integrierten Abhängigkeiten von Salesforce Platform-Metadaten. Für Anwendungsgeneratoren bieten die integrierten Services der Salesforce Platform zahlreiche Funktionen, die schnell konfiguriert werden können. Viele dieser Services verfügen über integrierte Abhängigkeiten, die es schwierig machen, sie in Funktionseinheiten auf niedriger Ebene zu abstrahieren. Für einen bestimmten Metadatentyp müssen Sie verstehen, wo sie im Spektrum der integrierten Abhängigkeiten liegen, und dieses Verständnis verwenden, um Ihre Paketabhängigkeitsketten zu definieren. Beginnen Sie nicht mit der Paketakzeptanz, indem Sie versuchen, die lose Kopplung in eine standardmäßige Plattformfunktion mit vielen integrierten Abhängigkeiten zu erzwingen. Dadurch wird die Komplexität (kein Wert) erhöht, wenn Sie Funktionen höherer Ordnung erreichen. Es ist auch eine andere Möglichkeit, in standardmäßige und benutzerdefinierte Antimuster zu fallen. Paketmetadaten von unten (wenigste Abhängigkeiten) nach oben – und wiederholen sich im Laufe der Zeit.
• Beobachten Sie Ihre Abhängigkeitsketten. Vermeiden Sie das Erstellen von Paketabhängigkeitsketten, bei denen Entwickler ihre Änderungen jederzeit in viele verschiedene Pakete aufteilen müssen.
• Überlegen Sie, was für die Quellcodeverwaltung sinnvoll ist. Es gibt zwei grundlegende Möglichkeiten, Ihre Pakete in der Quellcodeverwaltung zu verwalten. Bei der ersten handelt es sich um ein einzelnes Monorepository mit Paketen, die in Ordnern isoliert sind. Bei der zweiten handelt es sich um mehrere Repositorys, deren Pakete in ihren eigenen Repositorys isoliert sind. Die Verwaltung jeder Art von Quellstrategie ist langfristig komplex. Bei der Einarbeitung von Entwicklern sind vertikale Grenzen in mehreren Repository-Paradigmen effizienter. Horizontale Grenzen sind in einem Monorepo besser verständlich. Wieder können Sie Strategien mischen und abgleichen, während Ihre Architektur reift.

Die folgende Liste der Muster und Anti-Muster zeigt, wie eine ordnungsgemäße (und schlechte) Abhängigkeitsverwaltung mit Salesforce-Paketen aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für die Abhängigkeitsverwaltung finden Sie unter Tools Relevant to Composable (Für Composable relevante Tools).

In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster für die Paketierbarkeit im Explorer für Muster und Anti-Muster.

Helfen Sie uns, Salesforce Well-Architected für Sie relevant zu halten. Nehmen Sie an unserer Umfrage teil, um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.