MVP-001-DOMAIN-MODEL

MVP-001 – Kanonisches Domänenmodell#

Zweck#

Dieses Dokument definiert das technologieunabhängige Domänenmodell für den ersten produktiven Vertical Slice der Engineering Platform.

Es beschreibt ⌘BedeutungBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen., Identitäten, Verantwortlichkeiten, Beziehungen und Invarianten. Es legt ausdrücklich noch keine MariaDB-Tabellen, Go-Typen, REST-Ressourcen oder JavaScript-ViewModels fest.

Fachliche Grenze#

Das Modell umfasst den kleinsten produktiv tragfähigen Zusammenhang für:

• Benutzer und Berechtigungen,
• Artefakte und Revisionen,
• Beziehungen und Beziehungsrevisionen,
• Dimensionen,
• mehrsprachige Inhalte in de, en und uk,
• Terminologiebezug,
• manuell startbare automatische Übersetzungen,
• Review und ⌘FreigabeEin Release ist ein bewusst freigegebener und nachvollziehbarer Stand von Artefakten und ihrer Realisierung.,
• Audit und Nachvollziehbarkeit,
• Roundtrip-Aufträge und Arbeitspakete.

UI-Sprache und Artefaktsprache sind unabhängige Dimensionen.

Aggregate und Domänenobjekte#

1. User#

Ein User repräsentiert eine handelnde Person oder einen technischen Akteur.

Identität

• stabile UserId

Kernattribute

• Anzeigename
• Login-Identität
• Status
• bevorzugte UI-Sprache: de, en oder uk
• aktive Terminologiegruppe, sofern gesetzt
• zugeordnete Rollen

Verantwortung

• liefert den Akteur für Autorisierung, Revisionen, Reviews, Freigaben, Übersetzungsaufträge und Audit-Ereignisse.

2. Role#

Eine Role bündelt Berechtigungen.

Identität

• stabile RoleId

Kernattribute

• kanonischer Rollenname
• Beschreibung
• Berechtigungen
• Status

Invariante

Eine Rolle verleiht Berechtigungen; sie ersetzt keine fachliche Ownership eines Artefakts.

3. Artifact#

Ein ⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. ist die sprachunabhängige Identität eines fachlichen oder technischen Inhalts.

Identität

• stabile ArtifactId

Kernattribute

• kanonischer Artefakttyp
• Status
• Owner
• Sichtbarkeit
• fachliche Heimat
• aktuelle freigegebene Revision
• Erstellungs- und Änderungsmetadaten

Verantwortung

• bündelt Revisionen, Sprachvarianten, Dimensionen und Beziehungen.
• bleibt identisch, auch wenn Inhalte, Sprache, Speicherformat oder Materialisierung wechseln.

Invariante

Ein Artefakt darf nicht durch Dateipfad, Dateiname, Sprache oder Datenbank-ID fachlich identifiziert werden.

4. ArtifactRevision#

Eine ArtifactRevision ist ein unveränderlicher fachlicher Stand eines Artefakts.

Identität

• stabile ArtifactRevisionId

Kernattribute

• ArtifactId
• Revisionsnummer oder Revisionsfolge
• strukturierter Inhalt
• Änderungsgrund
• Autor
• Erstellungszeitpunkt
• ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung.
• vorherige Revision
• Status

Invarianten

• Eine gespeicherte Revision wird nicht überschrieben.
• Eine Änderung erzeugt eine neue Revision.
• Jede Revision verweist auf genau ein Artifact.
• Herkunft und Akteur müssen nachvollziehbar sein.

5. ArtifactLocalization#

Eine ArtifactLocalization repräsentiert die sprachliche Ausprägung eines Artefakts.

Identität

• stabile ArtifactLocalizationId

Kernattribute

• ArtifactId
• Sprachcode: de, en oder uk
• aktuelle Lokalisierungsrevision
• Übersetzungsstatus
• Quellsprache
• Quellrevision
• Terminologiebezug
• Review- und Freigabestatus

Invarianten

• Pro Artifact und Sprache existiert höchstens eine aktive Lokalisierungsidentität.
• Die Lokalisierung verändert nicht die ArtifactId.
• Eine maschinelle Übersetzung ist niemals automatisch fachlich freigegeben.
• Ändert sich die zugrunde liegende Quellrevision, kann die Zielvariante den Status outdated erhalten.

6. ArtifactLocalizationRevision#

Eine ArtifactLocalizationRevision ist ein unveränderlicher Stand einer Sprachvariante.

Identität

• stabile ArtifactLocalizationRevisionId

Kernattribute

• ArtifactLocalizationId
• Inhalt
• Revisionsfolge
• Übersetzungsherkunft
• Quellrevision
• Autor oder technischer Akteur
• Reviewstatus
• Freigabestatus
• Zeitpunkt

Zulässige Übersetzungszustände

• missing
• draft
• machine-translated
• review-required
• reviewed
• approved
• outdated

7. Relationship#

Eine ⌘RelationshipEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. ist die stabile Identität einer gerichteten oder ungerichteten fachlichen Beziehung zwischen zwei Artefakten.

Identität

• stabile RelationshipId

Kernattribute

• SourceArtifactId
• TargetArtifactId
• kanonischer Beziehungstyp
• Richtung
• Status
• Owner
• Gültigkeitsbereich
• aktuelle Revision

Invarianten

• Quelle und Ziel müssen existieren.
• Der Beziehungstyp bestimmt erlaubte Richtung und Kardinalität.
• Beziehungen werden nicht als unstrukturierte Links im Text ersetzt.
• Die Beziehung bleibt unabhängig von ihrer Darstellung in Markdown, HTML oder UI.

8. RelationshipRevision#

Eine RelationshipRevision ist ein unveränderlicher Stand einer Relationship.

Identität

• stabile RelationshipRevisionId

Kernattribute

• RelationshipId
• Quell- und Zielbezug
• Beziehungstyp
• Dimensionswerte
• Änderungsgrund
• Akteur
• Zeitpunkt
• vorherige Revision

9. DimensionDefinition#

Eine DimensionDefinition beschreibt eine zulässige Klassifikations- oder Kontextdimension.

Identität

• stabile DimensionDefinitionId

Beispiele

• Sprache
• Terminologie
• Organisation
• Rolle
• Gültigkeitskontext
• Sicherheitsklassifikation
• ⌘PlateauEin Plateau ist ein zeitlich eingeordneter, freigegebener Reife- oder Materialisierungsstand.
• Baseline

Kernattribute

• kanonischer Name
• Wertebereich
• Kardinalität
• anwendbare Objekttypen
• Validierungsregeln
• Status

Invariante

Dimensionen werden nicht als beliebige Key-Value-Sammlung ohne Definition geführt.

10. DimensionValue#

Ein DimensionValue ist ein zulässiger Wert einer DimensionDefinition.

Identität

• stabile DimensionValueId

Kernattribute

• DimensionDefinitionId
• kanonischer Wert
• lokalisierte Bezeichnung
• Status
• Gültigkeit

11. DimensionAssignment#

Ein DimensionAssignment ordnet einem Artefakt, einer Revision, einer Lokalisierung oder einer Beziehung einen Dimensionswert zu.

Identität

• stabile DimensionAssignmentId

Invarianten

• Zielobjekt, DimensionDefinition und DimensionValue müssen zusammenpassen.
• Kardinalitätsregeln der DimensionDefinition werden eingehalten.
• Historisch relevante Änderungen sind revisions- oder auditierbar.

12. TranslationJob#

Ein TranslationJob beschreibt einen bewusst gestarteten Übersetzungsauftrag.

Identität

• stabile TranslationJobId

Kernattribute

• Quell-Lokalisierungsrevision
• Zielsprache
• Terminologiegruppe
• ausführender Connector
• Auftraggeber
• Status
• Ergebnis-Lokalisierungsrevision
• Fehler- und Laufzeitinformationen

Lebenszyklus

requested → queued → running → completed | failed | cancelled

Invarianten

• Ein Job referenziert eine konkrete Quellrevision.
• Ein Ergebnis wird als neue Lokalisierungsrevision gespeichert.
• Ein erfolgreiches technisches Ergebnis ist noch keine fachliche Freigabe.
• Der Benutzer kann Übersetzungen nach en und uk beziehungsweise aus diesen Sprachen manuell anstoßen, sofern der Connector die Sprachrichtung unterstützt.

13. TerminologyContext#

Ein TerminologyContext legt fest, welche Terminologie für Darstellung oder Übersetzung gilt.

Identität

• stabile TerminologyContextId

Kernattribute

• Terminologiegruppe
• Sprache
• Rolle oder Nutzungskontext
• Strategie wie Preserve, Replace oder Translate
• Gültigkeit

Der TerminologyContext ersetzt nicht die ArtifactLocalization, sondern beeinflusst deren Darstellung oder Erzeugung.

14. ReviewDecision#

Eine ReviewDecision dokumentiert Prüfung, Korrektur, Freigabe oder Ablehnung einer Revision.

Identität

• stabile ReviewDecisionId

Kernattribute

• Zielrevision
• Entscheider
• Entscheidung
• Begründung
• Zeitpunkt

Invariante

Review und Freigabe sind explizite Handlungen und dürfen nicht aus einem bloßen Speichervorgang abgeleitet werden.

15. AuditEvent#

Ein AuditEvent ist ein unveränderlicher Nachweis einer sicherheits-, fach- oder prozessrelevanten Handlung.

Identität

• stabile AuditEventId

Kernattribute

• Akteur
• Aktion
• Zielobjekt
• vorherige und neue Revision
• Zeitpunkt
• RequestId
• RoundtripId, sofern vorhanden
• Herkunft
• Ergebnis
• Änderungsgrund

Invarianten

• Audit-Ereignisse werden nicht fachlich überschrieben.
• Geheimnisse und unnötige personenbezogene Inhalte gehören nicht in Audit-Nutzdaten.
• Berechtigungsentscheidungen und relevante Änderungen sind nachvollziehbar.

16. RoundtripJob#

Ein RoundtripJob repräsentiert den fachlichen Auftrag zwischen Mensch, Engineering Platform, Engineering Tools und AI-Transport.

Identität

• stabile RoundtripJobId

Kernattribute

• Auftraggeber
• Scope
• ausgewählte Artefakte und Ausgangsrevisionen
• Status
• Transportadapter
• Validierungsergebnisse
• Annahme- oder Ablehnungsentscheidung
• Promotionstatus

Lebenszyklus

draft → prepared → exported → returned → validating → review-required → accepted | rejected → promoted

17. RoundtripPackage#

Ein RoundtripPackage ist eine transportierbare Materialisierung eines RoundtripJob.

Identität

• stabile RoundtripPackageId

Kernattribute

• PackageType
• Manifest
• enthaltene Artefakt- und Revisionsreferenzen
• Prüfsumme
• Erzeugungszeitpunkt
• Herkunft
• Status

Das Paket ist nicht die führende fachliche Quelle, sondern eine Austauschmaterialisierung.

Zentrale Beziehungen#

User ──< UserRole >── Role

                Artifact ──< ArtifactRevision
                Artifact ──< ArtifactLocalization ──< ArtifactLocalizationRevision

                Artifact ──< Relationship >── Artifact
                Relationship ──< RelationshipRevision

                DimensionDefinition ──< DimensionValue
                Artifact / Revision / Localization / Relationship ──< DimensionAssignment

                ArtifactLocalizationRevision ──< TranslationJob
                ArtifactLocalizationRevision ──< ReviewDecision

                User / SystemActor ──< AuditEvent

                RoundtripJob ──< RoundtripPackage
                RoundtripJob ──< ArtifactRevisionReference
                RoundtripJob ──< ValidationResult

Aggregate-Grenzen#

Für den ersten Stand gelten folgende fachliche Aggregate:

• Artifact als Root für Artefaktidentität, Artefaktrevisionen und Sprachvarianten.
• Relationship als eigener Aggregate Root.
• TranslationJob als eigener Aggregate Root.
• User und Role als Identity-and-Access-Aggregate.
• RoundtripJob als eigener Aggregate Root.
• AuditEvent als append-only Nachweisobjekt.
• DimensionDefinition und DimensionValue als kontrollierter Referenzbestand.

Eine Transaktion darf mehrere Aggregate koordinieren, sofern Application ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung. und Audit die Änderung explizit führen. Kein Aggregate darf interne Zustände eines anderen Aggregates direkt verändern.

Materialisierungsregel#

Aus diesem Domain Model werden später getrennt abgeleitet:

Domain Model
                → Persistence Model
                → Go Domain Types und Ports
                → API Model
                → JavaScript ViewModels
                → Runtime Components

Keine dieser Materialisierungen darf das Domain Model stillschweigend neu definieren.

UAM-Vertragsbezug#

Dieses Domain Model materialisiert den Vertrag aus ◆MVP-001-unified-artifact-model-realization.mdSolutionweiter Realisierungsvertrag für Artefaktidentität, Revision, Lokalisierung, Beziehungen und kontrollierte Materialisierungen.. Identifier- und Reference-Resolution-Regeln werden in ◆MVP-001-identifier-and-reference-contract.mdVerbindlicher Vertrag für stabile Identifier, Referenzarten und deren Auflösung über Persistenz und Materialisierungen hinweg., Materialisierung und Provenance in ◆MVP-001-materialization-and-provenance-contract.mdVerbindlicher Vertrag für Materialisierungen, Herkunft, Roundtrip-Deltas und verlustarme Wiedereinspielung. geführt. Die Domänenobjekte dürfen diese solutionweiten Verträge präzisieren, aber keine konkurrierende Identitäts- oder Roundtrip-Semantik einführen.