ARTIFACT-MANIFEST-MODEL

Artifact-Manifestmodell#

Zweck#

⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. Manifests verbinden größere Implementierungsblöcke maschinenlesbar mit ihrer fachlichen ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung.. Sie ermöglichen Traceability vom ⌘CodeCode ist eine ausführbare oder interpretierbare technische Realisierung, die durch Tests und Runtime-Evidence überprüfbar bleibt. über Solution und Enterprise Architecture bis zur ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung., ohne Metadaten auf Funktions- oder Dateiebene zu erzwingen.

Geltungsbereich#

Ein Manifest wird auf einer sinnvollen Modulgrenze geführt, insbesondere für:

• vertikale Solution Building Blocks,
• Backend-Module,
• Frontend-Module,
• Adaptergruppen,
• Application-Bereiche,
• Port-Gruppen,
• Runtime-Komponenten.

Verbindliches Format#

Für MVP-001 wird artifact-manifest.json verwendet. JSON ist ohne zusätzliche Parser zuverlässig validierbar. Andere Materialisierungen wie YAML können später aus demselben Modell erzeugt werden.

Kernfelder#

manifestVersion
                artifact.id
                artifact.type
                artifact.name
                artifact.status
                realizes.vision
                realizes.capabilities
                realizes.referenceBuildingBlocks
                realizes.solutionBuildingBlocks
                realizes.requirements
                implements.domainObjects
                implements.ports
                implements.runtimeComponents
                documentation
                ownership
                quality.tests
                quality.requiredChecks

Regeln#

1. Fachliche IDs werden nicht im gesamten Quellcode dupliziert.
2. Ein Manifest liegt am Root des beschriebenen Moduls.
3. Änderungen an Verantwortung, Scope, öffentlichen Ports, Requirements oder Runtime-Materialisierung erfordern eine Manifestanpassung.
4. Interne Refactorings ohne semantische Auswirkung erfordern keine Manifeständerung.
5. Referenzen müssen auf existierende Architekturartefakte oder deklarierte Implementierungselemente zeigen.
6. Ein Manifest ist selbst ein Artefakt und kann später in die Engineering Platform importiert werden.

Traceability#

Vision
                → Capability
                → Reference Building Block
                → Solution Building Block
                → Requirement
                → Implementation Module
                → Runtime Component
                → Test