MVP-001-SOLUTION-PRINCIPLES

MVP-001 – Lösungsprinzipien#

Zweck#

Diese Leitplanken konkretisieren die geerbten Enterprise-Prinzipien für MVP-001. Sie definieren keine universelle Ontologie und ersetzen keine detaillierten Solution Contracts oder SADRs.

Universelle Foundation-Regeln werden im enterprise-architecture:30-principles/enterprise-foundation-principle-catalog.md geführt. Dieses Dokument spezialisiert ausschließlich ihre Konsequenzen für MVP-001.

SP-001 – Eine fachliche Wahrheit#

Jede fachliche Aussage besitzt genau eine führende Quelle. Datenbank, Markdown, HTML, UI, Reports und ZIPs sind kontrollierte Zustände oder Materialisierungen und dürfen keine konkurrierenden Wahrheiten bilden.

Konsequenz: Import, Export und Roundtrip müssen Identität, Revision, ⌘ProvenanceProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung. und Verantwortlichkeit erhalten.

SP-002 – Artifact und Relationship first#

Fachlich relevante Einheiten und ihre Beziehungen werden als identifizierbare, typisierte und historisierbare Artefakte behandelt. Dateipfade, UI-Views oder Tabellen sind keine fachlichen Primärobjekte.

Konsequenz: Komponenten- und Datenmodelle müssen auf das gemeinsame Artifact- und Relationship-Modell zurückführen.

SP-003 – Keine Parallelrealisierungen#

Neue Funktionen erweitern bestehende solutionweite Verträge und gemeinsame Komponenten. Zweite Editor-, Merge-, Translation-, Navigation- oder Orchestrierungsmodelle sind nur nach ausdrücklicher Architekturentscheidung zulässig.

Konsequenz: Vor neuen Komponenten ist Wiederverwendung oder Erweiterung zu prüfen.

Konkret gelten weiterhin die historischen Solution-Regeln P-003, P-004, P-010 und P-011: Beschreibungstexte verwenden den zentralen RichText- Editor; Textkonflikte verwenden die bestehende Links/Mitte/Rechts-Abgleichs-UI. Parallele Editoren oder Merge-Dialoge sind nicht zulässig.

SP-004 – Reasoning before rendering#

Fachliche Auswahl, Auflösung, Validierung und Erklärung erfolgen vor der Darstellung. ⌘RendererEin Renderer erzeugt eine konkrete technische Ausgabeform aus einer vorbereiteten Dokumentationsprojektion. Beispiele sind HTML, PDF, Markdown, JSON oder ein Suchindex. und Publisher präsentieren bereits bestimmte Ergebnisse und definieren keine eigene Semantik.

Konsequenz: Search, Help, Explainability und Publishing verwenden gemeinsame Resolution- und Reason-Code-Verträge.

SP-005 – Asynchrone externe Dienste#

Translation-, AI- und Connector-Aufrufe blockieren nicht das Speichern fachlicher Änderungen.

Konsequenz: Externe Verarbeitung wird als nachvollziehbarer Job mit Status, Fehlergrund und erneuter Ausführbarkeit modelliert.

Fachanwendungen integrieren LibreTranslate, Argos, Ollama, lokale LLMs oder externe AI-Dienste nicht direkt. Jede AI-Funktion läuft über den solutionweiten AI ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung.. Das Speichern fachlicher Daten darf weder von AI noch von Translation-, Netzwerk- oder Background-Job-Ausführung blockiert werden.

SP-006 – Environment Neutrality#

Führende Artefakte, Source Contracts und Building Blocks enthalten keine hart codierten Hosts, Ports, Pfade, Secrets oder Runtime-Namen.

Konsequenz: Konkrete Werte werden ausschließlich durch Runtime- und Deployment-Konfiguration bereitgestellt.

SP-007 – Documentation and Evidence as Product#

Contracts, Decisions, Requirements und Verification ⌘EvidenceTechnical documentation artifact. gehören zur produktiven Lösung und sind nicht bloße Begleittexte.

Konsequenz: Eine Änderung gilt erst als architektonisch vollständig, wenn ihre Rückverfolgbarkeit und Verifikation dokumentiert sind.

Passende Backend- und/oder End-to-End-Tests sind Bestandteil des Abschlussnachweises. Lokale Entwicklung, Setup und Betrieb werden so dokumentiert, dass ein ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities. reproduzierbar eingebunden und geprüft werden kann.

SP-008 – Erweiterung statt Wegwerf-MVP#

MVP-001 ist ein kleiner produktiver Kern. Nachgelagerte Funktionen erweitern seine Verträge, ohne Identität, Datenbestand oder zentrale Interaktionsmodelle neu aufzubauen.

Konsequenz: bewusste Erweiterungspunkte werden erhalten; vorsorgliche Vollimplementierung bleibt außerhalb des ⌘MVPEin MVP ist eine kleinste überprüfbare Materialisierung mit bewusst begrenztem Umfang..

Die Plattform bleibt auf Entwicklungsrechnern und im lokalen Netzwerk lauffähig. Externer Webbetrieb ist eine zusätzliche Materialisierung und keine Voraussetzung der lokalen Entwicklung.

SP-009 – Open Source und minimale Abhängigkeiten#

Externe Komponenten und Frameworks werden nur genutzt, wenn Lizenz, Betrieb und Wartbarkeit geprüft sind. Open-Source-Komponenten mit klarer Lizenz werden bevorzugt. Bestehende Plattformfunktionen und Standardbibliotheken haben Vorrang vor neuen Abhängigkeiten.

Konsequenz: Eine neue Abhängigkeit benötigt dokumentierten Nutzen, Lizenzprüfung und die Begründung, warum keine bestehende Lösung genügt.

SP-010 – Deutsche technische Standardsprache#

Deutsch (de) ist die technische Standardsprache von MVP-001. Ein Zustand ohne definierte Standardsprache ist unzulässig. Das Modell bleibt für beliebig viele weitere Sprachen offen.

Konsequenz: Sprachunabhängige IDs und lokalisierbare Inhalte bleiben getrennt; eine weitere Sprache erzeugt keine neue fachliche Identity.

SP-011 – Universumsbezogene Fachdaten#

Fachliche Artifacts, Stereotypes, Übersetzungen und Relationships gehören zu einem Universum, sofern sie fachlich innerhalb dieses Universums entstehen.

Konsequenz: Universumsgrenzen werden in Daten-, Service- und Autorisierungsverträgen erhalten und nicht aus UI-Kontext abgeleitet.

SP-012 – Autonome End-to-End-Tests#

End-to-End-Tests bauen ihre Testdaten selbst auf, prüfen den Roundtrip und räumen danach auf. Sie dürfen nicht von manuell vorhandenen Daten abhängen.

Konsequenz: Testdaten besitzen erkennbare Identitäten; Cleanup wird auch nach einem fehlgeschlagenen Test versucht.

Migrationsprovenienz#

Die solution-spezifischen Regeln konsolidieren P-003 bis P-011, P-013, P-015, P-016, P-019 und P-020 aus SolutionArchitecture:20-principles/PRI-001-Architecture-Principles.md, Version 0.3. Die vollständige Disposition aller 29 Legacy-Regeln steht in SE-0014 – Regelinventar und Übernahmematrix.

Prüffragen#

Vor ⌘PromotionTechnical documentation artifact. einer Änderung ist mindestens zu beantworten:

1. Welche führende fachliche Aussage wird geändert?
2. Welche Enterprise-Bedeutung oder ⌘CapabilityEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung. wird spezialisiert?
3. Welcher Solution Contract und welche Realisierung sind betroffen?
4. Entsteht eine Parallelarchitektur oder ein umgebungsabhängiger Vertrag?
5. Welche Requirement- und Testartefakte weisen die Änderung nach?