Ein Remote ist keine Komponentenbibliothek

Dass zwei Remotes dieselbe oder eine ähnliche Funktion benötigen, rechtfertigt keine horizontale Abhängigkeit zwischen ihnen.

Ein Remote ist eine eigenständig lauffähige Anwendung und ein fachlich verantworteter Bereich. Es ist kein Laufzeit-SDK, keine Komponentenbibliothek und kein Lieferant interner Services für andere Remotes.

Diese Abgrenzung wird unangenehm, sobald eine Funktion zum zweiten Mal benötigt wird. Denn aus Sicht der Implementierung scheint die Antwort häufig offensichtlich zu sein:

Diese Funktion gibt es doch bereits. Warum verwenden wir sie nicht einfach wieder?

Die Frage ist berechtigt. Die naheliegende Antwort ist es nicht immer.

Bevor eine bestehende Implementierung geteilt wird, muss zunächst geklärt werden, ob tatsächlich dieselbe Fachlichkeit vorliegt. Zwei Oberflächen können heute identisch aussehen und sich morgen aus vollkommen unterschiedlichen fachlichen Gründen verändern.

Erst danach lässt sich sinnvoll zwischen drei Möglichkeiten entscheiden:

• einer bewussten Mehrfachimplementierung,
• einer Shared Library,
• einer eigenständig verantworteten Capability.

Keine dieser Varianten ist grundsätzlich reifer als die anderen. Sie lösen unterschiedliche Probleme und erzeugen unterschiedliche Formen von Kopplung.

Diese Funktion gibt es doch schon

Angenommen, ein Kalender-Remote besitzt bereits eine Patientenauswahl. Über ein Suchfeld können Patienten gefunden und aus einer Ergebnisliste ausgewählt werden.

Nun benötigt auch das Abrechnungs-Remote eine Patientenauswahl.

Die scheinbar einfache Lösung sieht so aus:

Remote B
   │
   └── verwendet Patientenauswahl aus Remote A

Technisch könnte Remote B Quellcode direkt aus dem Projekt von Remote A importieren, eine veröffentlichte Runtime-API aufrufen, ein Fragment aus Remote A laden oder sogar das gesamte Remote einbetten. Die konkrete Form verändert die Art der Kopplung, nicht aber die grundlegende Architekturentscheidung.

Bei einem Quellcode-Import entstehen Build- und Versionskopplung: Remote B greift auf Interna eines anderen fachlichen Projekts zu. Bei einer Runtime-API oder einem eingebetteten Fragment kommen gekoppelte Verfügbarkeit, Aktivierung und Lebenszyklen hinzu.

In allen Varianten wird Remote B horizontal von Remote A abhängig.

Für die lokale Entwicklung und isolierte Tests von Remote B werden dadurch möglicherweise Code, Verträge oder sogar die laufende Instanz von Remote A benötigt. Rollbacks und unterschiedliche Aktivierungsstände werden schwieriger. Fehler lassen sich nicht mehr eindeutig dem konsumierenden oder dem liefernden Remote zuordnen.

Vor allem verändert sich die Verantwortung von Remote A.

Das Kalender-Team entwickelt nicht mehr nur den Kalender. Es muss nun zusätzlich einen stabilen Vertrag für fremde Consumer bereitstellen. Interne Komponenten, Services oder Datenmodelle werden faktisch zu öffentlichen APIs. Änderungen, die innerhalb des Kalenders unproblematisch wären, können nun andere Remotes beschädigen.

Aus einem fachlichen Bereich wird nebenbei eine Plattform für andere fachliche Bereiche.

Das geschieht häufig ohne bewusste Entscheidung. Der erste Implementierungsort wird zum Lieferanten, weil dort der Code bereits existiert. Technische Verfügbarkeit ersetzt die Klärung von Ownership.

Eine Anwendung wird jedoch nicht zur Bibliothek, nur weil eine ihrer Funktionen an anderer Stelle ebenfalls gebraucht wird.

Ist es wirklich dieselbe Fachlichkeit?

Die Behauptung, zwei Remotes benötigten exakt dieselbe Fachlichkeit, sollte zunächst als Hypothese behandelt werden.

Betrachten wir die Patientenauswahl in drei Bereichen.

Im Kalender wird ein Patient ausgewählt, um einen Termin zu planen. In der Abrechnung wird ein Patient ausgewählt, um eine Rechnung oder einen Kostenträger zuzuordnen. In der Dokumentation wird ein Patient ausgewählt, um ein Dokument zu erstellen oder abzulegen.

Alle drei Oberflächen können zunächst nahezu identisch aussehen:

• ein Suchfeld,
• eine Ergebnisliste,
• Name und Geburtsdatum,
• möglicherweise der Versicherungsstatus.

Diese visuelle Ähnlichkeit sagt wenig über ihre fachliche Bedeutung aus.

Für die Terminplanung könnte entscheidend sein, ob ein Patient in der ausgewählten Einrichtung behandelt werden darf, ob Terminwarnungen vorliegen oder ob ein Bezug zu einem bestimmten Behandler besteht.

Für die Abrechnung könnten der Kostenträger, bestehende Abrechnungssperren, der Rechnungsstatus oder besondere Versicherungsinformationen relevant sein.

Für die Dokumentation könnten Zugriffsrechte, Archivierungsregeln, der rechtssichere Name oder der konkrete Dokumentkontext bestimmen, ob und wie ein Patient ausgewählt werden darf.

Damit unterscheiden sich nicht nur die angezeigten Zusatzinformationen. Auch die Gründe, aus denen sich die jeweilige Funktion verändert, sind andere.

Eine neue Abrechnungsregel betrifft möglicherweise ausschließlich die Patientenauswahl der Abrechnung. Eine neue Regel zur Dokumentenarchivierung betrifft ausschließlich die Dokumentation. Eine Einschränkung bei der Terminvergabe darf nicht automatisch die Auswahl in anderen Bereichen verändern.

Gleiche Darstellung ist kein Beweis für gleiche Fachlichkeit.

Die entscheidende Frage lautet deshalb:

Was geschieht, wenn beide Remotes morgen widersprüchliche Anforderungen an die vermeintlich gemeinsame Funktion stellen?

Muss die gemeinsame Komponente dann beide Varianten unterstützen, wächst ihre Schnittstelle schnell um optionale Parameter, fachliche Flags und Consumer-spezifische Callbacks. Unterschiedliche Modelle werden in gemeinsamen Typen zusammengeführt. Switch-Logik entscheidet, welcher fachliche Kontext gerade aktiv ist.

Die Implementierung wird zwar weiterhin nur einmal ausgeliefert. Ihre Bedeutung ist aber nicht mehr gemeinsam. Sie enthält mehrere fachliche Varianten, deren Unterschiede hinter einer technischen Abstraktion verborgen werden.

Bewusste Duplizierung kann die sauberere Entscheidung sein

Duplizierung wird in der Softwareentwicklung häufig reflexartig als Fehler behandelt. Dadurch entsteht ein starker Anreiz, Gemeinsamkeiten möglichst früh zu abstrahieren.

Bei fachlichen Grenzen kann genau das die teurere Entscheidung sein.

Wenn die Patientenauswahl im Kalender und in der Abrechnung unterschiedliche Bedeutungen besitzt, dürfen beide Remotes eine eigene Implementierung haben:

Kalender-Remote
└── eigene Patientenauswahl für Terminplanung

Abrechnungs-Remote
└── eigene Patientenauswahl für Abrechnung

Beide Implementierungen können dieselben Design-Tokens, Eingabefelder, Tabellenkomponenten oder technischen Suchmechanismen verwenden. Sie müssen deshalb nicht dieselbe fachliche Komponente teilen.

Dabei sollten drei Ebenen getrennt betrachtet werden:

1. gemeinsames Aussehen,
2. gemeinsame technische Bausteine,
3. gemeinsame fachliche Bedeutung.

Ein einheitliches Erscheinungsbild kann durch ein Design-System abgesichert werden. Wiederkehrende technische Mechanismen können in technischen Libraries liegen. Daraus folgt noch nicht, dass auch die fachliche Auswahl gemeinsam implementiert werden muss.

Bewusste Mehrfachimplementierung ist insbesondere dann plausibel, wenn sich die Funktionen aus unterschiedlichen Gründen verändern, verschiedene Teams verantwortlich sind, unterschiedliche Backend-Verträge verwendet werden oder eine fachliche Auseinanderentwicklung wahrscheinlich ist.

Der zusätzliche Code ist dann nicht automatisch Verschwendung. Er kauft unabhängige Veränderbarkeit.

Das bedeutet allerdings keinen Freibrief für unkontrolliertes Copy-and-paste. Die Entscheidung zur Duplizierung sollte bewusst getroffen und dokumentiert werden. Die Implementierungen dürfen sich anschließend auseinanderentwickeln. Es besteht kein Anspruch darauf, sie dauerhaft synchron zu halten.

Sollte sich später zeigen, dass Bedeutung, Verhalten und Änderungsgründe über längere Zeit tatsächlich identisch bleiben, kann weiterhin eine gemeinsame Abstraktion entstehen. Eine spätere Zusammenführung ist meist einfacher als die Auflösung einer vorschnell geschaffenen gemeinsamen Verantwortung.

Mehrfacher Implementierungsaufwand kann wirtschaftlich sinnvoller sein als dauerhafte Koordination über mehrere Verantwortungsbereiche.

Ähnlichkeit ist noch keine Abstraktion

Eine gemeinsame Abstraktion sollte eine stabile Gemeinsamkeit ausdrücken. Sie sollte nicht lediglich die aktuelle Ähnlichkeit zweier Implementierungen konservieren.

Gerade fachliche UI-Komponenten wirken am Anfang oft universeller, als sie tatsächlich sind. Die erste Version unterstützt einen Consumer. Der zweite Consumer benötigt eine zusätzliche Option. Der dritte benötigt einen Callback an einer Stelle, die ursprünglich interner Bestandteil des Ablaufs war.

Mit jedem neuen Consumer wächst die Konfiguration:

Patientenauswahl
├── Modus Kalender
├── Modus Abrechnung
├── Modus Dokumentation
├── optionale Warnungen
├── austauschbare Ergebnisdarstellung
├── Callback vor Auswahl
├── Callback nach Auswahl
└── Sonderfälle pro Remote

Die Abstraktion beseitigt die Unterschiede nicht. Sie verschiebt sie in eine größere Property-API, in Flags und in bedingte Abläufe.

Spätestens wenn zentrale Typen mehrere Fachsprachen vermischen oder kein beteiligtes Team eine Anforderung ablehnen kann, ist aus Wiederverwendung ein gemeinsamer Verhandlungspunkt geworden.

Eine Abstraktion sollte gemeinsame Stabilität ausdrücken, nicht gegenwärtige Ähnlichkeit konservieren.

Wann eine Shared Library sinnvoll ist

Eine Shared Library ist eine plausible Lösung, wenn tatsächlich dieselbe stabile Implementierung geteilt werden soll.

Bei technischen Libraries ist das häufig vergleichsweise einfach zu begründen. Logging, Telemetrie, Design-Tokens, Basiskomponenten, technische Fehlerbehandlung oder eine Auth-Client-Abstraktion besitzen bewusst einen breiten und stabilen Vertrag. Ihre Bedeutung hängt nicht vom jeweiligen fachlichen Consumer ab.

Auch Formatierungsfunktionen, Internationalisierungsmechanismen oder klar abgegrenzte Protokolltypen können sinnvoll geteilt werden.

Eine fachliche Shared Library stellt höhere Anforderungen.

Sie ist nur dann sinnvoll, wenn ihre Semantik in allen Consumern wirklich identisch ist. Änderungen müssen aus denselben fachlichen Gründen entstehen. Alle Consumer müssen dasselbe Verhalten benötigen. Außerdem muss feststehen, wer über den gemeinsamen Vertrag entscheidet.

Ein Beispiel könnte ein gesetzlich eindeutig definierter Berechnungsalgorithmus sein, dessen Bedeutung in allen verwendenden Bereichen identisch ist. Auch ein fachlicher Validator kann geteilt werden, wenn er überall exakt dieselbe Regel repräsentiert und nicht je nach Kontext unterschiedlich ausgelegt werden darf.

Eine fachliche Shared Library ist kein neutraler Ablageort. Sie ist ein gemeinsam verwendetes Produkt mit eigenem Vertrag.

Dazu gehört auch, Anforderungen abzulehnen, die ausschließlich einen einzelnen Consumer betreffen. Andernfalls wächst die gemeinsame Implementierung erneut zu einer Sammlung fachlicher Varianten.

Eine Shared Library beseitigt Kopplung nicht

Durch eine Shared Library lässt sich die direkte Laufzeitabhängigkeit zu einem anderen Remote vermeiden:

Remote A ─┐
Remote B ─┼── Shared Library
Remote C ─┘

Kein Remote muss zur Laufzeit auf ein anderes warten. Lokale Entwicklung und Betrieb bleiben voneinander getrennt.

Damit ist jedoch nicht jede Kopplung verschwunden.

Die Consumer hängen weiterhin von Versionen der Library ab. Änderungen müssen kompatibel bleiben oder bewusst migriert werden. Neue Releases benötigen Tests gegen mehrere Consumer. Bei Breaking Changes muss entschieden werden, ob alle Remotes gleichzeitig aktualisiert werden oder unterschiedliche Versionen unterstützt werden.

Auch der Projektgraph wird breiter. Wenn eine kleine Änderung an einer Shared Library zahlreiche Remotes und Hosts als betroffen markiert, ist das nicht nur ein Problem des Buildsystems. Es zeigt die Reichweite der gemeinsamen Abhängigkeit.

Eine Shared Library beseitigt Runtime-Kopplung. Sie beseitigt nicht automatisch organisatorische oder fachliche Kopplung.

Je zentraler die Library ist, desto größer ist außerdem ihr Einfluss auf Releaseentscheidungen, Priorisierung und technische Migrationen. Eine Änderung kann lokal klein sein und trotzdem eine breite Abstimmung erfordern.

Keine Runtime-Kopplung bedeutet noch keine unabhängige Veränderbarkeit.

„Shared“ ist kein Ownership-Modell

Sobald mehrere Remotes eine Library verwenden, entstehen Fragen, die nicht durch einen gemeinsamen Ordner beantwortet werden:

• Wer besitzt die Library?
• Wer entscheidet über Änderungen?
• Wer priorisiert Anforderungen der Consumer?
• Wer bewertet Breaking Changes?
• Wer veröffentlicht neue Versionen?
• Wer unterstützt ältere Versionen?
• Wer entscheidet bei widersprüchlichen Anforderungen?
• Darf ein Consumer auf einer älteren Version bleiben?
• Wer darf eine Anforderung ablehnen?

Eine Shared Library beseitigt Ownership nicht. Sie zentralisiert es.

Ohne klaren Owner entwickelt sie sich häufig zu einer gemeinsamen Ablage:

shared-domain
├── patient-picker
├── billing-rules
├── calendar-mapper
├── document-validator
└── diverse Sonderfälle

Jeder verwendet diese Library, aber niemand besitzt sie vollständig. Änderungen benötigen breite Abstimmung. Breaking Changes werden vermieden, weil sich niemand für die Migration aller Consumer verantwortlich fühlt. Sonderfälle sammeln sich an, da das Entfernen bestehender Varianten riskanter erscheint als das Hinzufügen einer weiteren Option.

Irgendwann ist die Library schwerer zu verändern als jeder einzelne Consumer.

Das Wort „shared“ beschreibt lediglich, dass mehrere Bereiche etwas verwenden. Es beantwortet nicht, wer dafür verantwortlich ist.

Der erste Implementierungsort bestimmt nicht den Owner

Die Patientenauswahl ist möglicherweise zuerst im Kalender entstanden. Später benötigen auch Abrechnung und Dokumentation eine ähnliche Fähigkeit.

Daraus folgt nicht, dass das Kalender-Team dauerhaft die gemeinsame Patientenauswahl besitzen sollte.

Das Team hat möglicherweise keine fachliche Verantwortung für Abrechnung oder Dokumentation. Es hat keinen Auftrag, eine Plattform für andere Bereiche zu betreiben. Seine Releaseprioritäten richten sich nach dem Kalender. Fremde Anforderungen konkurrieren daher zwangsläufig mit den eigentlichen Zielen des Teams.

Trotzdem entsteht schnell die Erwartung, das Kalender-Team müsse die Komponente stabilisieren, dokumentieren, versionieren und Support für andere Consumer leisten. Der historische Zufall der ersten Implementierung wird zur dauerhaften Organisationsstruktur.

Zufällige historische Entstehung ist kein tragfähiges Ownership-Modell.

Wenn eine Funktion wirklich gemeinsam werden soll, muss ihr Ownership bewusst neu entschieden werden. Das kann weiterhin beim ursprünglichen Team liegen, falls Auftrag und Verantwortung entsprechend erweitert werden. Es kann aber ebenso ein anderes Team, eine Plattformverantwortung oder eine eigenständige Capability entstehen.

Der vorhandene Code beantwortet diese Frage nicht.

Wann aus der Funktion eine eigenständige Capability wird

Manche Funktionen sind tatsächlich fachlich eigenständig und werden in mehreren Kontexten benötigt.

Eine umfassende Patientensuche kann beispielsweise weit mehr sein als ein Suchfeld mit Ergebnisliste. Sie kann Berechtigungen prüfen, Dubletten behandeln, unterschiedliche Suchstrategien anbieten, rechtliche Sichtbarkeitsregeln durchsetzen und eigene fachliche Prozesse besitzen.

Ähnliches gilt für einen komplexen Dokumenteneditor, einen Zahlungsprozess, einen rechtlich geregelten Signaturvorgang oder einen eigenständigen Reporting-Bereich.

In solchen Fällen reicht eine Library möglicherweise nicht aus. Die Funktion besitzt einen eigenen fachlichen Lebenszyklus und rechtfertigt eigenes Ownership, einen eigenen Betrieb und bewusst definierte Integrationspunkte.

Gemeinsame Capability
├── eigener fachlicher Vertrag
├── eindeutiger Owner
├── eigener Lebenszyklus
├── definierte Integrationspunkte
└── mehrere Hosts oder Nutzungskontexte

Eine solche Capability ist nicht einfach ein Fragment aus Remote A, das Remote B importiert.

Sie besitzt eine eigene fachliche Identität. Ihr Vertrag wird bewusst veröffentlicht. Fehlerverantwortung, Lebensdauer, Versionierung und Aktivierung sind geklärt. Die Integration erfolgt bevorzugt auf einer übergeordneten Kompositionsebene oder über einen ausdrücklich dafür vorgesehenen Vertrag.

Das ist etwas anderes als ein verschachteltes Remote, das nur deshalb in einem anderen Remote erscheint, weil dort bereits die benötigte Oberfläche existiert.

Verschachtelte Remotes koppeln Verfügbarkeit und Lebenszyklen. Routing- und Fehlerverantwortung werden schwieriger. Die lokale Entwicklung benötigt mehrere Anwendungen. Für Nutzer ist oft unklar, welcher Bereich die sichtbare Gesamtfunktion besitzt.

Eine gemeinsam genutzte Capability braucht einen eigenen Owner. Sie sollte nicht zufällig dem ersten Remote gehören, in dem sie entstanden ist.

Drei mögliche Entscheidungen

Bewusste Mehrfachimplementierung

Remote A → eigene Umsetzung
Remote B → eigene Umsetzung

Diese Variante ist sinnvoll, wenn Bedeutung oder Regeln unterschiedlich sind, eine Auseinanderentwicklung erwartet wird oder unabhängige Releases wichtiger sind als eine zentrale Implementierung.

Ihr Nutzen liegt in klarer Ownership und unabhängiger Veränderbarkeit. Es gibt keine gemeinsame Versionierung und keinen zentralen Vertrag, der mehrere Fachbereiche zugleich bedienen muss.

Dafür fallen Implementierungs- und Testaufwand mehrfach an. Fehler müssen möglicherweise an mehreren Stellen behoben werden. Außerdem können sich Darstellung und Verhalten unbeabsichtigt unterscheiden.

Shared Library

Remote A ─┐
Remote B ─┼── versionierte Shared Library

Diese Variante ist sinnvoll, wenn Bedeutung und Verhalten tatsächlich identisch sind, die Implementierung ausreichend stabil ist und ein eindeutiger Owner einen bewusst veröffentlichten Vertrag betreibt.

Sie ermöglicht konsistentes Verhalten und zentrale Fehlerbehebung. Die Implementierung wird an einer Stelle gepflegt.

Dafür entstehen Versions- und Governance-Kopplung. Änderungen haben breitere Auswirkungen. Migrationen müssen koordiniert und Consumer unterstützt werden. Ownership wird zentralisiert.

Eigenständige Capability

Host oder Komposition
├── Remote A
├── Remote B
└── eigenständige Capability

Diese Variante ist sinnvoll, wenn die Fähigkeit einen eigenen fachlichen Lebenszyklus besitzt, in mehreren Hosts oder Nutzungskontexten benötigt wird und größer als ein einfacher Library-Baustein ist.

Sie erhält einen klaren fachlichen Vertrag, eindeutiges Ownership und eine unabhängige Weiterentwicklung.

Dafür entstehen zusätzliche Laufzeitintegration, Deployment- und Betriebsverantwortung. Observability, Fehlerbehandlung und Versionsmanagement müssen für eine weitere Anwendung gelöst werden.

Entscheidungsfragen

Für die Entscheidung ist keine feste Scoring-Matrix notwendig. Einige Fragen machen jedoch sichtbar, welche Form von Gemeinsamkeit tatsächlich vorliegt:

• Ist die fachliche Bedeutung identisch oder nur die Darstellung ähnlich?
• Ändern sich beide Vorkommen aus denselben Gründen?
• Müssen beide immer dasselbe Verhalten besitzen?
• Dürfen sie sich fachlich auseinanderentwickeln?
• Verwenden sie denselben Backend-Vertrag?
• Ist die Funktion außerhalb des ursprünglichen Remotes eigenständig sinnvoll?
• Wer besitzt den gemeinsamen Vertrag?
• Wer entscheidet bei widersprüchlichen Anforderungen?
• Können Consumer unterschiedliche Versionen verwenden?
• Ist eine synchrone Migration akzeptabel?
• Wie groß ist der tatsächliche Implementierungsaufwand der Duplizierung?
• Wie hoch ist der langfristige Koordinationsaufwand des Sharings?
• Ist die Fähigkeit groß genug für einen eigenen Lebenszyklus?
• Würde eine gemeinsame Implementierung fachliche Unterschiede verstecken?

Die wichtigste Prüfungsfrage bleibt:

Was geschieht, wenn beide Remotes morgen unterschiedliche Anforderungen an die vermeintlich identische Funktion stellen?

Die Antwort darauf zeigt häufig deutlicher als jede technische Analyse, ob wirklich eine gemeinsame Fähigkeit vorliegt.

Wiederverwendung ist eine wirtschaftliche Entscheidung

Duplizierung kostet zusätzliche Implementierung, mehrere Tests und möglicherweise mehrfache Fehlerbehebung. Parallele Implementierungen können inkonsistent werden und müssen unabhängig gepflegt werden.

Sharing kostet Abstimmung, Versionierung, Governance, zentrale Priorisierung und Support für Consumer. Breaking Changes müssen geplant werden. Builds und Tests betreffen mehr Projekte. Der vermiedene doppelte Code kann über Jahre mit zusätzlicher Koordination bezahlt werden.

Eine eigenständige Capability verursacht wiederum eigene Kosten: Laufzeitintegration, Deployment, Betrieb, Observability, Vertragspflege und eindeutige Fehlerverantwortung.

Keine dieser Kostenarten ist grundsätzlich geringer. Sie treten lediglich an unterschiedlichen Stellen und zu unterschiedlichen Zeitpunkten auf.

Die relevante Frage lautet daher nicht, wie möglichst viel Code wiederverwendet werden kann. Entscheidend ist, welche Verantwortung dauerhaft gemeinsam getragen werden soll.

Wiederverwendung ist nicht kostenlos. Sie tauscht mehrfachen Implementierungsaufwand gegen gemeinsame Verantwortung.

Fazit

„Wir brauchen exakt dieselbe Fachlichkeit in zwei Remotes“ ist keine Begründung, sondern eine Annahme, die geprüft werden muss.

Ist nur die Oberfläche ähnlich, während Bedeutung, Regeln und Änderungsgründe verschieden sind, kann eine bewusste Mehrfachimplementierung die sauberere fachliche Grenze erhalten.

Sind Semantik und Lebenszyklus tatsächlich identisch und stabil, kann eine Shared Library sinnvoll sein. Dann benötigt sie jedoch einen klaren Vertrag, Versionierung und einen eindeutigen Owner.

Besitzt die Fähigkeit einen eigenen fachlichen Lebenszyklus, kann sie als eigenständige Capability verantwortet und auf einer geeigneten Kompositionsebene integriert werden.

In keinem dieser Fälle sollte Remote B einfach horizontal von Remote A abhängig werden.

Teile eine Implementierung nur dann, wenn auch ihre Bedeutung, ihr Lebenszyklus und ihre Verantwortung wirklich geteilt werden sollen.