Trenne allgemeine und projektspezifische Architektur
This commit is contained in:
gitea_admin committed
1 parent
18d73dd4d5
commit
985ada2f39
1 file changed
+37
-24
@@ -116,28 +116,6 @@ Verbindliche Regel:
|
||||
- wenn Text im DOM sichtbar ist, gilt er als GUI-String und unterliegt dieser Regel auch dann, wenn er clientseitig zusammengesetzt wird
|
||||
- zusammengesetzte UI-Texte duerfen keine fachliche Logik enthalten; sie kombinieren nur locale-gebundene Textbausteine mit stabilen technischen Werten
|
||||
|
||||
### 2.5 GUI-/MCP-Paritaet
|
||||
|
||||
Die MCP-Schnittstelle ist im Grundsatz funktional paritaetisch zur GUI. Ein
|
||||
MCP-Nutzer ist hinsichtlich der fachlichen Nutzung einem GUI-Nutzer
|
||||
gleichzustellen.
|
||||
|
||||
Verbindliche Regel:
|
||||
|
||||
- jeder fachliche Anwendungsfall, den ein GUI-Nutzer ausfuehren kann, muss auch
|
||||
ueber die MCP-Schnittstelle ausfuehrbar sein
|
||||
- alle fachlichen Lese-, Anlege-, Aenderungs-, Archivierungs- und
|
||||
Reaktivierungsmoeglichkeiten der GUI muessen im MCP-Interface abgebildet sein
|
||||
- GUI und MCP verwenden dieselben fachlichen Validierungen, Berechtigungen,
|
||||
Statusregeln und Ownership-Grenzen; fachliche Logik darf nicht doppelt in
|
||||
GUI und MCP implementiert werden
|
||||
- jede Erweiterung oder Aenderung eines GUI-Anwendungsfalls erfordert zwingend
|
||||
die gleichzeitige Pruefung und, falls erforderlich, Anpassung des MCP-Interfaces
|
||||
- ein MCP-Nutzer darf gegenueber einem gleich berechtigten GUI-Nutzer weder
|
||||
fachlich eingeschraenkt noch durch abweichende Regeln bevorzugt werden
|
||||
- die Paritaet betrifft die fachliche Funktion und den Datenzugriff, nicht die
|
||||
visuelle Darstellung oder den Interaktionsablauf der GUI
|
||||
|
||||
## 3. Modulmodell
|
||||
|
||||
### 3.1 Zulaessige Modulbereiche
|
||||
@@ -148,7 +126,6 @@ Fachliche Hauptmodule:
|
||||
- `ratings`
|
||||
- `groups`
|
||||
- `lists`
|
||||
- `market_management`
|
||||
|
||||
Technische Modulbereiche:
|
||||
|
||||
@@ -203,6 +180,7 @@ Verbindliche Regel:
|
||||
|
||||
- jede Tabelle, View, materialisierte View und DB-Funktion besitzt genau eine primaere Ownership
|
||||
- primaere Ownership folgt genau einem Hauptmodul oder einem technischen Shared-Bereich
|
||||
- fachliche Beziehungen sowie Ownership- und Berechtigungsschluessel verwenden stabile interne Entitaets-IDs; veraenderliche Attribute wie E-Mail, Username oder Anzeigename duerfen dafuer nicht verwendet werden
|
||||
- nur das owning Modul definiert Struktur, Write-Logik, Constraints und fachliche Semantik eines DB-Artefakts
|
||||
- direkte Cross-Modul-Writes in fremde Owned Tabellen sind verboten
|
||||
- andere Module duerfen fremde Artefakte nur ueber definierte Schnittstellen des owning Moduls nutzen
|
||||
@@ -287,7 +265,7 @@ Prueffragen vor jeder Erweiterung:
|
||||
|
||||
Verbindliche Regel:
|
||||
|
||||
- neue Hauptmodule sind nur zulaessig, wenn eine neue fachliche oder technische Primaerverantwortung entsteht, die nicht sauber in `company`, `ratings`, `groups`, `lists`, `market_management`, `system` oder `shared` aufgeht
|
||||
- neue Hauptmodule sind nur zulaessig, wenn eine neue fachliche oder technische Primaerverantwortung entsteht, die nicht sauber in `company`, `ratings`, `groups`, `lists`, `system` oder `shared` aufgeht
|
||||
- neue Submodule sind nur zulaessig, wenn innerhalb eines bestehenden Hauptmoduls eine klar isolierbare Verantwortung mit eigener Schnittstelle entsteht
|
||||
- neue Prozess- und Sub-Prozess-Dokumente werden im owning Modulpfad angelegt und folgen `component.subcomponent.process_name`
|
||||
- `admin`, `public/api/`, `scripts/` oder `lib/` begruenden kein neues fachliches Hauptmodul
|
||||
@@ -303,3 +281,38 @@ Verbindlich ist:
|
||||
- `docs/technical_architecture.md` ist der einzige aktive Architektur-Master des Repositories
|
||||
- andere Dokumente duerfen diese Architektur erklaeren, anwenden oder historisieren, aber keine konkurrierende Master-Struktur definieren
|
||||
- konkrete Inventare wie Tabellenlisten, Submodullisten, Prozesslisten oder Runtime-Artefakte werden in Detaildokumenten gepflegt und nicht hier dupliziert
|
||||
|
||||
## 10. Projektspezifische Architekturvorgaben
|
||||
|
||||
Dieses Kapitel enthaelt Architekturentscheidungen, die fuer dieses Projekt
|
||||
gelten und nicht Teil der allgemeinen, projektuebergreifend wiederverwendbaren
|
||||
Modularitaet sind.
|
||||
|
||||
### 10.1 Fachliches Hauptmodul `market_management`
|
||||
|
||||
Dieses Projekt besitzt zusaetzlich das fachliche Hauptmodul
|
||||
`market_management`. Seine fachliche Ownership, Datenstruktur und
|
||||
Schnittstellen werden in den Modulvertraegen unter
|
||||
`docs/modules/market_management/` dokumentiert.
|
||||
|
||||
### 10.2 GUI-/MCP-Paritaet
|
||||
|
||||
Die MCP-Schnittstelle ist im Grundsatz funktional paritaetisch zur GUI. Ein
|
||||
MCP-Nutzer ist hinsichtlich der fachlichen Nutzung einem GUI-Nutzer
|
||||
gleichzustellen.
|
||||
|
||||
Verbindliche Regel:
|
||||
|
||||
- jeder fachliche Anwendungsfall, den ein GUI-Nutzer ausfuehren kann, muss auch
|
||||
ueber die MCP-Schnittstelle ausfuehrbar sein
|
||||
- alle fachlichen Lese-, Anlege-, Aenderungs-, Archivierungs- und
|
||||
Reaktivierungsmoeglichkeiten der GUI muessen im MCP-Interface abgebildet sein
|
||||
- GUI und MCP verwenden dieselben fachlichen Validierungen, Berechtigungen,
|
||||
Statusregeln und Ownership-Grenzen; fachliche Logik darf nicht doppelt in
|
||||
GUI und MCP implementiert werden
|
||||
- jede Erweiterung oder Aenderung eines GUI-Anwendungsfalls erfordert zwingend
|
||||
die gleichzeitige Pruefung und, falls erforderlich, Anpassung des MCP-Interfaces
|
||||
- ein MCP-Nutzer darf gegenueber einem gleich berechtigten GUI-Nutzer weder
|
||||
fachlich eingeschraenkt noch durch abweichende Regeln bevorzugt werden
|
||||
- die Paritaet betrifft die fachliche Funktion und den Datenzugriff, nicht die
|
||||
visuelle Darstellung oder den Interaktionsablauf der GUI
|
||||
Reference in new issue
Block a user