README

Architekturvertrag#

Zweck#

Der Architecture Contract bestimmt die verbindliche Rangfolge der Quellen, nach denen die Enterprise Architecture entwickelt und materialisiert wird. Er verhindert, dass einzelne Chats, Implementierungen oder Ablagestrukturen implizit neue Architektur festlegen.

Führende Reihenfolge#

1. Architecture Contract und Constitution
2. freigegebene Architecture Decisions
3. gültige Baselines
4. ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung. und ihre ausdrücklich beschriebenen Materialisierungen
5. Repository Contracts
6. Reference Artifacts, Reference Models, Reference Processes und Reference Patterns
7. beauftragter Sprint-Scope
8. vorhandener Repositoryzustand und technische Implementierung

Die vorhandene Implementierung ist niemals die Quelle einer Architekturentscheidung. Sie ist eine Materialisierung, die gegen die führenden Quellen geprüft wird.

Vision und Materialisierung#

Die Vision beschreibt die langfristig gewünschte Wirkung und Ausrichtung. Das ⌘MVPEin MVP ist eine kleinste überprüfbare Materialisierung mit bewusst begrenztem Umfang. ist nicht die Vision selbst, sondern die erste bewusst begrenzte Materialisierung der Vision. Ein ⌘PlateauEin Plateau ist ein zeitlich eingeordneter, freigegebener Reife- oder Materialisierungsstand. ist ein validierter Materialisierungsstand.

Für die erste Generation-2-Materialisierung gilt das aus der bisherigen Solution Architecture übernommene MVP-SETUP.md als verbindlicher Ausgangspunkt. Seine Aussagen werden nicht stillschweigend geändert. Widersprüche und notwendige Weiterentwicklungen werden als Findings oder Architecture-Decision-Vorschläge dokumentiert.

Reference-Artifacts-Grundsatz#

Dauerhaft wiederverwendbare Konzepte werden zunächst semantisch beschrieben. Dabei gilt:

Reference Artifacts beschreiben ⌘BedeutungBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen.. Templates beschreiben technische Materialisierung.

Reference Artifacts, Reference Models, Reference Processes und Reference Patterns sind keine bloßen Dokumentvorlagen. Sie sind kanonische semantische Quellen, aus denen Markdown, JSON, Datenbankstrukturen, HTML, UI oder weitere Darstellungen materialisiert werden können.

Repository-Verträge#

Jedes dauerhaft geführte Repository erhält einen Repository Contract. Dieser beschreibt mindestens:

• kanonische Repository-Identität,
• Zweck und Verantwortungsgrenze,
• erlaubte Inhalte,
• explizite Ausschlüsse,
• Beziehungen zu anderen Repositories,
• Struktur- und Nummerierungsregeln,
• Packaging- und Roundtrip-Regeln,
• Runtime-Trennung,
• Qualitäts- und Promotion-Regeln.

Änderungsregel#

Der Contract wird niemals implizit verändert. Fehlen Informationen oder widersprechen sich führende Quellen, wird die Arbeit angehalten, soweit eine Entscheidung notwendig ist, und das Problem als ⌘FindingTechnical documentation artifact. oder ADR-Vorschlag dokumentiert. Innerhalb eines klar abgegrenzten Sprints dürfen ausschließlich die beauftragten Materialisierungen verändert werden.

Beziehungen#

• 20-vision/ enthält Vision und Materialisierungen.
• 85-reference-artifacts/ enthält die semantische Foundation.
• 95-baselines/ beschreibt freigegebene Materialisierungsstände.
• 96-architecture-decisions/ enthält ausdrücklich beschlossene Abweichungen oder Konkretisierungen.
• engineering-tools materialisiert und validiert technische Darstellungen, definiert aber nicht deren semantische Bedeutung.

Architektur-Realisierungskette#

Die verbindliche Ableitungskette lautet:

Vision
                → Enterprise Description
                → Enterprise Capability
                → Reference Building Block
                → Solution Building Block
                → Implementation Module
                → Runtime Component

Dabei gelten folgende Regeln:

• Jede Ebene materialisiert Aussagen der unmittelbar höheren Ebene und definiert sie nicht neu.
• Reference Building Blocks sind lösungsneutral und wiederverwendbar.
• Solution Building Blocks materialisieren Reference Building Blocks im Kontext einer konkreten Solution.
• Implementierungsmodule materialisieren Solution Building Blocks in ⌘CodeCode ist eine ausführbare oder interpretierbare technische Realisierung, die durch Tests und Runtime-Evidence überprüfbar bleibt., Datenstrukturen, Schnittstellen und Tests.
• Runtime Components sind konkrete laufende Instanzen dieser Implementierung.
• Traceability muss vom Runtime Component bis zur Vision möglich sein.
• Fehlt eine nachvollziehbare Ableitung, ist die Umsetzung nicht promotionsfähig.

Related Architecture#

• Vision – constrained-by
• Architecture Decisions – realized-through
• Reference Artifacts – realized-through
• ◆Enterprise Knowledge GraphDokumentiert die semantischen Beziehungen zwischen den tragenden Enterprise-Artefakten. – related-to