MVP-001-REFERENCE-REALIZATION-MAPPING
MVP-001 – Referenz-zu-Lösungs-Building-Block-Zuordnung#
Zweck#
Dieses Dokument verbindet die lösungsneutralen Reference Building Blocks der Enterprise Architecture mit den konkreten Solution Building Blocks von MVP-001.
Es bildet die verbindliche Realisierungskette:
Enterprise Capability
→ Reference Building Block
→ Solution Building Block
→ Backend-/Frontend-Modul
→ Persistenzobjekte und Verträge
→ Tests
→ Runtime Component
Die Reference Building Blocks definieren GlossarbegriffBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen.Glossareintrag vollständig lesen und wiederverwendbare Verantwortung. Die Solution Building Blocks spezialisieren diese Verantwortung für die Engineering Platform. Implementierungsmodule und Runtime Components materialisieren die Solution Building Blocks.
Mapping#
| Reference GlossarbegriffEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities.Glossareintrag vollständig lesen | Solution Building Block | Backend | Frontend | Persistenz | Runtime |
|---|---|---|---|---|---|
| Platform Shell | BB-EP-001 Platform Shell |
internal/platformshell |
src/shell |
Konfiguration und technische Runtime-Metadaten | Engineering-Platform-Webprozess |
| Identity & Access | BB-EP-002 Identity & Access |
internal/identity |
src/identity |
users, roles, user_roles, user_preferences, sessions |
Engineering-Platform-Webprozess |
| GlossarbegriffEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. Alles Modellierbare wird als Artefakt geführt. Dazu gehören unter anderem Systeme, Beziehungen, Features, Dokumente, ADRs, Tests, UI-Buttons, Menüs, Farben, Icons, Konfigurationen, Diagramme, Runtime-Ressourcen, fachliche Objekte und reale Objekte wie ein Blumentopf, sofern sie modelliert werden. Knowledge ist keine Sonderklasse. UI- und Applikationsartefakte werden fachlich nach demselben Grundmodell behandelt.Glossareintrag vollständig lesen Management | BB-EP-003 Artifact Management |
internal/artifacts |
src/artifacts |
artifacts, artifact_versions, artifact_metadata |
Engineering-Platform-Webprozess |
| GlossarbegriffEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext.Glossareintrag vollständig lesen Management | BB-EP-004 Relationship Management |
internal/relationships |
src/relationships |
relationships, relationship_versions, relationship_types, dimensions, relationship_dimensions |
Engineering-Platform-Webprozess |
| Localization | BB-EP-005 Localization |
internal/localization |
src/localization |
artifact_localizations, artifact_localization_versions |
Engineering-Platform-Webprozess |
| Terminology | BB-EP-006 Terminology |
internal/terminology |
src/terminology |
terminology_groups, terms, term_definitions, term_translations |
Engineering-Platform-Webprozess |
| Translation | BB-EP-007 Translation |
internal/translation |
src/translation |
translation_jobs, translation_job_results |
Webprozess und Background Worker; externer Translation GlossarbegriffEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung.Glossareintrag vollständig lesen |
| Audit & Traceability | BB-EP-008 Audit & Traceability |
internal/audit |
src/audit |
audit_events, Revisions- und Korrelationsdaten |
Engineering-Platform-Webprozess |
| Roundtrip | BB-EP-009 Roundtrip Orchestration |
internal/roundtrip |
src/roundtrip |
roundtrip_jobs, roundtrip_packages, roundtrip_items, validation_results, roundtrip_decisions |
Webprozess, Background Worker und Engineering-Tools-Ausführung |
| Persistence | BB-EP-010 Persistence |
internal/persistence |
keine fachliche UI | Migrationen, Transaktionen, Outbox und technische Persistenzadapter | MariaDB |
| Runtime Integration | BB-EP-011 Runtime Integration |
internal/runtimeintegration |
src/runtime |
Deployment- und Jobstatus, soweit fachlich erforderlich | Test- und Produktionsruntime |
| Knowledge & Guidance | BB-EP-012 Knowledge & Guidance Management |
internal/knowledge |
src/knowledge |
Knowledge-, Help-, Provider- und Explainability-Artefakte über veröffentlichte Repository Ports | Engineering-Platform-Webprozess |
| Bootstrap & Installation | BB-EP-013 Bootstrap & Installation Management |
Installation-Orchestrierung über veröffentlichte Ports | Status- und Verification-Sichten | Installationspläne, Verification GlossarbegriffTechnical documentation artifact.Glossareintrag vollständig lesen und technische Bootstrap-Zustände | Runtime- und Engineering-Tools-Ausführung |
Verbindliche Regeln#
REAL-001 – Referenzpflicht#
Jedes Solution Building Block muss mindestens einen Reference Building Block referenzieren. Ein Solution Building Block ohne Referenz ist nur mit einer dokumentierten Architecture Decision zulässig.
REAL-002 – Keine Neuinterpretation#
Die Solution Architecture darf Zweck und Kernverantwortung eines Reference Building Blocks nicht stillschweigend verändern. Lösungsspezifische Ergänzungen werden als Spezialisierung dokumentiert.
REAL-003 – Keine erzwungene Eins-zu-eins-Beziehung#
Ein Reference Building Block kann durch mehrere Solution Building Blocks materialisiert werden. Ein Solution Building Block kann mehrere eng gekoppelte Reference Building Blocks kombinieren, wenn Ownership und Grenzen eindeutig bleiben.
REAL-004 – Traceability bis zur Runtime#
Für jeden implementierten Scope muss die Kette bis zu mindestens einem Implementierungsmodul, Test und Runtime Component nachvollziehbar sein.
REAL-005 – Wiederverwendung#
Eine weitere Solution übernimmt Reference Building Blocks und deren Contracts. Sie übernimmt nicht automatisch die Go-, JavaScript-, Datenbank- oder Runtime-Materialisierung der Engineering Platform.
REAL-006 – Abweichungen#
Abweichungen vom Reference Building Block werden mit Grund, Auswirkung, Kompatibilität und gegebenenfalls ADR dokumentiert.
Ownership und Dependency#
Die verbindliche primäre Ownership und die zulässigen direkten Abhängigkeiten stehen in ArtifactMVP-001 – Building-Block-Verantwortungs- und AbhängigkeitsmatrixFührende Zuordnung fachlicher Ownership, veröffentlichter Grenzen und zulässiger Abhängigkeiten der Solution Building Blocks.Vollständig lesen.
Beziehung zu anderen Dokumenten#
- Die fachlichen Solution Building Blocks stehen in ArtifactMVP-001 – Building-Block-KarteTechnical documentation artifact.Vollständig lesen.
- Die Abhängigkeits- und Modularitätsregeln stehen in ArtifactMVP-001 – Modularitäts- und AbhängigkeitsregelnTechnical documentation artifact.Vollständig lesen.
- Die Capability-Realisierung steht in MeaningMVP-001 – Capability-RealisierungFührender Einstieg für Scope, Realisierungsbeiträge und Verification der MVP-001 Capabilities.Vollständig lesen.
- Die Laufzeitkomponenten stehen in Kontext & ZeitMVP-001 – Runtime-ZielKompakte Zieldefinition für getrennte MVP-Runtime-Umgebungen.Vollständig lesen.
- Die zugrunde liegenden Reference Building Blocks werden in der Enterprise Architecture definiert.
Capability-Bezug#
Die Zuordnung aktueller Solution Building Blocks zu MVP-Capabilities wird ausschließlich in MeaningMVP-001 – Capability-Traceability-MatrixVerbindet die ausgewählten Enterprise Capabilities mit aktuellen Solution Building Blocks, Requirements und Verification-Artefakten.Vollständig lesen geführt. Historische Building-Block-IDs sind keine führenden Ziel-IDs.