EP-001A-DOMAIN-MODEL

EP-001A – Implementierungsgrenze des Domain Model#

Zweck#

Diese Datei bindet die Engineering Platform an das kanonische Domain Model der Solution Architecture.

Die führende Definition liegt in:

solution-architecture/70-data/MVP-001-domain-model.md
                solution-architecture/70-data/EP-001A-domain-invariants.md

Die Engineering Platform definiert diese Begriffe nicht neu.

Geplante Modulgrenzen#

10-backend/
                └── internal/
                    ├── identity/
                    ├── artifacts/
                    ├── relationships/
                    ├── localization/
                    ├── terminology/
                    ├── translation/
                    ├── audit/
                    ├── roundtrip/
                    └── shared-kernel/

Der shared-kernel darf ausschließlich stabile technische Grundtypen enthalten, etwa fachliche IDs, Zeitquelle und Request-Kontext. Fachliche Logik verbleibt im zuständigen .

Zuordnung#

Domänenobjekt	Zuständiger Solution Building Block	Geplantes Backend-Modul
User, Role	BB-EP-002 Identity & Access	`internal/identity`
, ArtifactRevision	BB-EP-003 Artifact Management	`internal/artifacts`
, RelationshipRevision	BB-EP-004 Relationship Management	`internal/relationships`
ArtifactLocalization, LocalizationRevision	BB-EP-005 Localization	`internal/localization`
TerminologyContext	BB-EP-006 Terminology	`internal/terminology`
TranslationJob	BB-EP-007 Translation	`internal/translation`
AuditEvent, ReviewDecision	BB-EP-008 Audit & Traceability	`internal/audit`
RoundtripJob, RoundtripPackage	BB-EP-009 Roundtrip Orchestration	`internal/roundtrip`
DimensionDefinition, DimensionValue, Assignment	BB-EP-003/004 mit zentralem Contract	zunächst `internal/artifacts` und `internal/relationships`; keine freie Shared-Ablage

Verbindliche Implementierungsregeln#

Noch keine MariaDB-Tabellen in EP-001A.
Noch keine REST-DTOs in EP-001A.
Noch keine JavaScript-ViewModels in EP-001A.
Go-Typen werden erst im Arbeitspaket Backend aus dem Domain Model abgeleitet.
Persistenzadapter dürfen keine fachlichen Invarianten besitzen, die nicht im Domain Model dokumentiert sind.
Direkter Zugriff eines Moduls auf interne Typen eines anderen Moduls ist unzulässig.
Modulübergreifende Aktionen werden über veröffentlichte Ports, Commands oder Events koordiniert.
Die gemeinsame Binary ist zulässig; fachliche Vermischung ist es nicht.

Nächster Schritt#

EP-001B materialisiert dieses Modell als MariaDB-Persistence-Model mit Migrationen, Constraints, Outbox und Audit-Grundlage.