SE-0050-BUILDING-BLOCK-KONSOLIDIERUNG
SE-0050 – Building-Block-Modell aus Legacy konsolidieren#
Ergebnis#
Der historische Katalog SolutionArchitecture:70-building-blocks/BUILDING-BLOCKS.md bleibt historische Provenienz. Die aktuelle kanonische Beschreibung liegt ausschließlich in der ArtifactMVP-001 – Building-Block-KarteTechnical documentation artifact.Vollständig lesen, der 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 und dem ArtifactMVP-001 – Referenz-zu-Lösungs-Building-Block-ZuordnungMaps reusable Reference Building Blocks to solution-specific Building Blocks and their implementation/runtime materializations.Vollständig lesen.
Historische IDs werden nicht als aktuelle IDs fortgeführt. Ihre Bezeichnungen begründen weder zusätzliche Ownership noch eine Implementierungsbehauptung.
Disposition#
| Historische Kataloggruppe | Kanonische Zielverantwortung | Entscheidung |
|---|---|---|
| Platform Core, UI Orchestrator und Ribbon Management | BB-EP-001 Platform Shell |
als Shell-, Navigations- und Kompositionsverantwortung spezialisiert; keine Übernahme der historischen ID |
| Universe, Network Board, GlossarbegriffEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext.Glossareintrag vollständig lesen und Stereotype Management | BB-EP-003 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 und BB-EP-004 Relationship Management |
bestehende Artefakt- und Beziehungsgrenzen verwenden; Board- und Stereotypdetails werden nicht aus dem Katalog ergänzt |
| i18n UI, Translation Jobs, AI Client und AI Server | BB-EP-005 Localization, BB-EP-006 Terminology und BB-EP-007 Translation |
UI-Sprache, Artefaktinhalt, Terminologie und Translation bleiben getrennte Verantwortungen |
| Persistence Data Access, Background Jobs und Platform Deployment | BB-EP-008 Audit & Traceability, BB-EP-009 Roundtrip Orchestration, BB-EP-010 Persistence und BB-EP-011 Runtime Integration |
technische Infrastruktur bleibt von fachlicher Ownership getrennt |
| Terminology GlossarbegriffEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung.Glossareintrag vollständig lesen, User Management, Help System und Administration UI | BB-EP-002 Identity & Access, BB-EP-006 Terminology und BB-EP-012 Knowledge & Guidance Management |
nur die vorhandenen Zielverantwortungen werden referenziert; historische Bedienoberflächen definieren keine zusätzliche Zielarchitektur |
| Media Asset Management sowie WordPress-, Sparx- und Collaboration-Connectoren | keine eigenständige MVP-001-Zuordnung in diesem Sprint | keine belegte Übernahme in die aktuelle Building-Block-Map; als Legacy-Provenienz belassen |
Capability, Glossar und zeitlicher Kontext#
- Die Capability-Beiträge stehen ausschließlich in der MeaningMVP-001 – Capability-Traceability-MatrixVerbindet die ausgewählten Enterprise Capabilities mit aktuellen Solution Building Blocks, Requirements und Verification-Artefakten.Vollständig lesen; Building Blocks sind keine Capability-Eigentümer.
- Die Abgrenzung der Begriffe GlossarbegriffEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung.Glossareintrag vollständig lesen, Artifact, Relationship, Identity und GlossarbegriffTechnical documentation artifact.Glossareintrag vollständig lesen folgt den Enterprise Core Terms. Die zielseitige Terminologie- und Explainability-Spezialisierung ist im ArtifactMVP-001 – Wissens-, Terminologie- und ErklärbarkeitszuordnungZuordnung des Knowledge-Clusters zu aktuellen Solution Building Blocks.Vollständig lesen verlinkt.
- Die Relation des historischen Gesamtmodells zur Zielarchitektur ist
evolves_from, nicht GlossarbegriffDie Beziehung zeigt vom aktuellen, ablösenden Wissenselement auf den abgelösten Stand. Sie darf nur verwendet werden, wenn die Ablösung fachlich belegt ist; eine höhere Versionsnummer allein genügt nicht.Glossareintrag vollständig lesen; siehe Kontext & ZeitHistorische und aktuelle Gültigkeit in der SolutionSpezialisiert das Enterprise-Gültigkeitsnetz für Solution-Verträge, Entscheidungen und Revisionen.Vollständig lesen.
Coverage-Grenze#
Die Zuordnung ist Architektur- und Traceability-Evidence. Sie behauptet keine Vollständigkeit der Implementierung. Der tatsächlich direkt, indirekt oder noch nicht verifizierte Engineering-Stand steht in engineering-platform:96-documentation/EP-001-verification-coverage.md.
Related Architecture#
- MeaningMVP-001 – Building-Block-Governance-AnforderungenAnforderungen an Ownership, Mapping, Abhängigkeiten und Traceability der Solution Building Blocks.Vollständig lesen –
evidences - Kontext & ZeitMVP-001 – Building-Block-Governance-VerifikationsmatrixVerifikation von Ownership, Reference Mapping, Abhängigkeitsgrenzen und Building-Block-Traceability.Vollständig lesen –
verified-by