EA-CROSS-REPOSITORY-RESPONSIBILITY-001

Verantwortungsmodell für repositoryübergreifende Zusammenarbeit#

Übersicht · 2: zweite Ebene · Ziehen/Klicken: navigieren

Zweck#

Dieses Modell legt organisationsweit fest, welches Repository eine Aussage besitzt und welche Repositorys sie ausschließlich referenzieren, spezialisieren, materialisieren oder instanziieren. Es verhindert parallele Wahrheiten und entscheidet Ownership nach statt nach technischer Nähe oder vorhandener Ablagestruktur.

Kanonische Verantwortungsmatrix#

Repository	Besitzt kanonisch	Darf referenzieren oder spezialisieren	Besitzt ausdrücklich nicht
`enterprise-architecture`	universelle Bedeutungen, Prinzipien, Capabilities, Reference Models, organisationsweite Governance und übergreifende Learnings	validierte Materialisierungserfahrungen und solution-spezifische	Solution-Verträge, Produktimplementierung, Werkzeugmechanik oder Runtime-Zustand
`solution-architecture`	solutionweite Verträge, Spezialisierungen, Komponenten-, Service-, Daten-, Runtime- und Deployment-Grenzen	universelle Enterprise-Semantik	universelle Theorie, komponenteninterne Implementierung oder veränderliche Runtime-Werte
`engineering-platform`	repositorylokale Produktrealisierung und Engineering-Platform-Verträge	Enterprise- und Solution-Verträge sowie gemeinsame Tool-Schnittstellen	allgemeine Werkzeugmechanik oder mutable Runtime-Zustände
`engineering-tools`	gemeinsame, wiederverwendbare Werkzeugmechanik, ausführbare Validation, Packaging, Deployment und Tool Contracts	Architektur- und Produktverträge als technische Eingabe	Produktsemantik, Plattformmodule oder Runtime-Zustände
`runtime`	materialisierte Installationen, Konfigurationsorte, Environment-Grenzen und veränderliche Laufzeitzustände	freigegebene Architektur-, Produkt- und Tool-Artefakte als nicht-kanonische Materialisierung	Architekturentscheidungen, Engineering Contracts oder Werkzeugquellwissen
`workspace`	lokale Integrationsstruktur, historische Kompatibilitätsadapter und vollständige Arbeitskopien für kontrollierte Roundtrips	führende Architektur- und Toolverträge als Eingabe	neue dauerhafte Werkzeugmechanik, kanonische Architektur oder veränderlicher Runtime-Zustand

Ableitungs- und Übergangsregel#

Enterprise Architecture
                → Solution Architecture
                → Engineering Platform / Engineering Tools
                → Runtime

Eine tiefere Ebene darf eine höhere Ebene spezialisieren oder materialisieren, aber nicht stillschweigend neu definieren.
engineering-platform realisiert das Produkt; engineering-tools stellt gemeinsame Mechanik für Erzeugung, Prüfung, Packaging und Deployment bereit.
Runtime-Inhalte können vollständige materialisierte Kopien enthalten. Diese sind Evidence oder Installation, niemals neue kanonische Wissensquellen.
Workspace-Arbeitskopien dürfen zur nachvollziehbaren Übermittlung in Source und Target vorliegen. Diese Paketrolle erzeugt keine Ownership und aktiviert keine stillgelegte Prozesskette.
Jede fachliche Aussage besitzt genau eine führende Repository-Quelle.

Referenzkonvention#

Repositoryübergreifende Referenzen werden als stabile, repositoryqualifizierte Pfade notiert:

<repository-id>:<pfad-im-repository>

Beispiel:

enterprise-architecture:00-overview/cross-repository-responsibility-model.md

Solche Referenzen sind semantische Adressen. Sie werden nicht als relative Markdown-Links dargestellt, weil jedes Repository als eigenständiges Roundtrip-Paket ausgeliefert wird.

Lokale Verantwortungserklärungen#

Jedes Repository hält nur seine lokale Verantwortung und die Referenz auf dieses Modell fest. Es kopiert die vollständige Matrix nicht. Abweichungen benötigen eine Architecture Decision im zuständigen Repository.

Beziehungen#

— contributes_to