MVP-001-COMPONENT-AND-SERVICE-REALIZATION

MVP-001 – Komponenten- und Dienstrealisierung#

Zweck#

Dieses Dokument konsolidiert die solutionweite Komponentensicht. Es spezialisiert keine universelle Komponenten- oder Capability-Theorie, sondern ordnet die konkreten Verantwortungen der Engineering Platform.

Verbindliche Realisierungskette#

Solution Capability
                → Solution Building Block
                → Component Responsibility
                → Application Service / Port
                → Adapter oder Provider
                → Runtime Component
                → Requirement und Verification Evidence

Keine Ebene ersetzt die andere:

Building Blocks besitzen fachliche und technische Ownership.
Komponenten strukturieren die Solution und ihre Laufzeitverantwortungen.
Services veröffentlichen Use Cases, Queries, Commands und Ports.
Adapter binden Persistenz, Engineering Tools, Translation Provider und weitere externe Systeme an.
Runtime Components materialisieren die Verträge in einer konkreten Umgebung.

Primäre Komponenten#

Komponente	Primäre Verantwortung	Darf nicht besitzen
Workbench Shell	Composition Root, Perspective, Navigation, Ribbon, Knowledge Panel, gemeinsamer UI-Kontext	fachliche Use-Case-Logik, lokale Autorisierungsquelle
Contribution Framework	Laden, validieren, registrieren, filtern und binden deklarativer Contributions	fachliche Ownership der beitragenden Building Blocks
Application Backend	Commands, Queries, Workflow-Orchestrierung, Autorisierung und Transaktionsgrenzen	UI-spezifische Präsentationszustände
Domain Components	Artefakte, Beziehungen, Lokalisierung, Terminologie, Translation, Audit und Roundtrip gemäß Building-Block-Ownership	fremde Fachzuständigkeiten
Provider and Adapter Layer	kontrollierte Anbindung von Persistenz, Engineering Tools und externen Providern	fachliche Workflowentscheidung
Background Worker	asynchrone Jobs mit Status, Korrelation, Retry und	eigene fachliche Verträge neben den Application Services

Interaktionsregeln#

Die Workbench ruft Use Cases ausschließlich über veröffentlichte Application Services auf.
Commands werden über stabile CommandId referenziert; UI-Manifeste enthalten keine fachliche Handler-Implementierung.
Queries verändern keinen fachlichen Zustand.
Schreibende Use Cases führen fachliche Änderung, Revision, Audit und Outbox innerhalb der dokumentierten Transaktionsgrenze aus.
UI-Policy ist Darstellung; serverseitige Autorisierung bleibt führend.
Externe Systeme werden über Ports und Adapter angebunden. Direkte Zugriffe aus Frontend oder Domain sind unzulässig.
Context Binding aktualisiert alle gebundenen Workbench-Regionen aus einem gemeinsamen Zustand.