Architektur

Erstellt: 2025-12-27 | Aktualisiert: 2025-12-31

Clean Architecture Übersicht für das Campus-System. Strikte Trennung zwischen Backend (MVC), Frontend (MVP) und Infrastruktur.

Projekt-Root	/var/www/dev.campus.systemische-tools.de/
Backend	MVC Pattern (/src)
Frontend	MVP Pattern (/app)
Datenbanken	ki_dev, ki_content

Backend-Architektur (MVC)

Pfad: /src/

Verzeichnis	Zweck	Beispiele
Framework/	App-Kern, Router, Controller-Base	App.php, Router.php, Controller.php
Controller/	HTTP Controller (Request → Response)	TaskController, ChatController
Domain/	Entities, Repository-Interfaces	Task.php, TaskRepositoryInterface
UseCases/	Anwendungsfälle (Business Logic)	CreateTaskUseCase, ExecuteTaskUseCase
Infrastructure/	DB, External Services	TaskRepository, OllamaService
View/	Server-Templates (PHP)	tasks/index.php, chat/show.php

Layer-Regeln

Controller → UseCase → Repository (via Interface)
     ↓          ↓              ↓
   Request   Business     Infrastructure
   Handler    Logic         (MySQL, API)

VERBOTEN:
- Controller → Repository direkt (muss über UseCase)
- UseCase → Infrastructure konkret (nur Interface)
- View → Database (niemals)

Frontend-Architektur (MVP)

Pfad: /app/

Verzeichnis	Zweck	Beispiele
Presenter/	UI-Logik, View-Model Aufbereitung	TaskPresenter, ChatPresenter
View/	Passive Views (nur Anzeige)	TaskListView, ChatView

MVP-Prinzip

Model: Domain-Entities (aus /src/Domain)
View: Passive Templates, keine Logik
Presenter: Bereitet Daten für View auf, enthält UI-Logik

Datenbanken

Datenbank	Zweck	Beispiel-Tabellen
ki_dev	Infrastruktur/Development	tasks, contracts, dokumentation, mcp_log, file_backup_history
ki_content	Content/User-facing	chat_sessions, chat_messages, content, documents, chunks, entities

Zugriff

Kein direkter SQL-Zugriff! Immer über MCP-DB:

mcp__mcp-db__db_select(query, database="ki_dev")
mcp__mcp-db__db_insert(table, data, database="ki_content")

Verzeichnisstruktur

/var/www/dev.campus.systemische-tools.de/
├── app/                    # Frontend (MVP)
│   ├── Presenter/          # UI-Logik
│   └── View/               # Passive Views
├── bin/                    # CLI-Binaries
├── cli/                    # CLI-Commands
├── composer.json           # PHP Dependencies
├── composer.lock           # Lock-File
├── config/                 # Konfiguration
│   ├── config.php          # App-Config
│   ├── autoload.php        # PSR-4 Autoloader
│   ├── database.php        # DB-Config
│   └── profiles/           # Author-Profile
├── contracts/              # Architecture Contracts (YAML)
├── database/               # Migrations, Seeds
├── docs/                   # Projekt-Dokumentation
├── phpstan.neon            # PHPStan Config
├── phpstan-baseline.neon   # PHPStan Baseline
├── .php-cs-fixer.dist.php  # PHP-CS-Fixer Config
├── public/                 # Web-Root
│   ├── index.php           # Entry Point
│   ├── css/                # Stylesheets
│   ├── js/                 # JavaScript
│   ├── images/             # Bilder
│   └── static-docs/        # Statische Docs
├── routes/                 # Route-Definitionen
│   ├── web.php             # Web-Routes
│   └── api.php             # API-Routes
├── src/                    # Backend (MVC)
│   ├── Framework/          # App, Router, Controller-Base
│   ├── Controller/         # HTTP Controller
│   ├── Domain/             # Entity, Repository-Interfaces
│   ├── UseCases/           # Anwendungsfälle
│   ├── Infrastructure/     # DB, External Services
│   └── View/               # Server-Templates
├── storage/                # Logs, Cache, Sessions
│   ├── logs/               # Application Logs
│   ├── cache/              # Cache-Dateien
│   └── sessions/           # PHP-Sessions
├── tests/                  # Unit-Tests
│   └── Unit/               # PHPUnit Tests
└── vendor/                 # Composer Dependencies

Dependency Injection

Der DI-Container in /src/services.php bindet Interfaces an Implementierungen:

// Interface → Implementation
TaskRepositoryInterface::class => TaskRepository::class
OllamaServiceInterface::class => OllamaService::class

// Controller bekommt Dependencies via Constructor
class TaskController extends Controller {
    public function __construct(
        private TaskRepositoryInterface $taskRepository,
        private CreateTaskUseCase $createTask
    ) {}
}

Request-Lifecycle

1. Request → public/index.php
2. App::bootstrap() → Autoload, Config, DI-Container
3. Router::dispatch() → Route matchen
4. Controller::action() → UseCase aufrufen
5. UseCase → Repository → Database
6. View::render() → HTML Response
7. Response → Browser

Code-Analyse

Vor Refactoring immer MCP-Code nutzen:

# Klasse finden
mcp__mcp-code__code_search("TaskController")

# Dependencies prüfen
mcp__mcp-code__code_dependencies("Controller\\TaskController")

# Impact vor Änderung
mcp__mcp-code__code_impact("Domain\\Entity\\Task")