forked from fa/breadcrumb-the-shire
Rename the top-level lib/ directory to core/ so the project root immediately communicates which code is core platform and which lives in modules/. PHP namespaces (MintyPHP\*) are unchanged — only the Composer PSR-4 path mapping moves from lib/ to core/. Module-internal lib/ directories (modules/*/lib/) are untouched. Updated across the full stack: - composer.json PSR-4 mapping - bootstrap entry points (web/index.php, bin/*, tests/bootstrap.php) - tooling configs (phpstan.neon, phpunit.xml, php-cs-fixer) - 26 architecture contract tests - enforcement-policy, guard-catalog, quality-gates - all documentation (CLAUDE.md, README, 25 docs/, .agents/skills/) - bin/qa-extended.sh search paths - .claude/settings.local.json permission paths Workflow: .agents/runs/CORE-LIB-RENAME-001/ (Analyst → Planner → Executor → Code Review (4 findings fixed) → Security Review → Acceptance Test → Finalizer) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.0 KiB
3.0 KiB
Architektur und Request-Flow
Letzte Aktualisierung: 2026-03-06
Ziel
Verstehen, wo Änderungen hingehören und wo nicht.
Request-Flow
web/index.phplädt Bootstrap, registriert denAppContainerund setzt globale Service-Auflösung.RequestContextinitialisiertrequest_idund Basis-Metadaten;X-Request-Idwird gesetzt.- Guard/Sicherheitslayer laufen.
- Action in
pages/**nimmt Input an. - Action delegiert an Service.
- Service nutzt Repository für Datenzugriff.
- Response wird als HTML/JSON ausgegeben.
API-Ergänzung:
ApiBootstrap::init()startet API-Audit (ApiAuditService) und API-System-Audit (ApiSystemAuditReporter).ApiResponse::send()finalisiert beide Reporter (inkl.request_id-Korrelation).- System-Protokolle schreiben nur selektive
api.request-Events (kein Voll-Request-Logging).
Schichtregeln
pages/**: Input, Auth/AuthZ, Service-Aufruf, Response.core/Service/**: Business-Regeln und Orchestrierung.core/Repository/**: SQL, Filter, Mapping.templates/**: Rendering ohne Business-Logik.- Request-Daten in Actions nur über
requestInput()(keine Input-Superglobals). - Validierungsfehler zentral über
FormErrors; API-Fehler überApiResponse::validationFromFormErrors(...). - Template-AuthZ konsumiert nur vorbereitete
$viewAuth-Daten (keincan('...')im Template). - Service-Auflösung in Actions/Helpern über
app(Foo::class). - Fachliche Audit-Events laufen zentral über
SystemAuditService. - Persistierte Status/Outcome-Werte laufen über die zentrale Taxonomie-Schicht
core/Domain/Taxonomy/*(Enums + DB-Checks). pages/**/data().phpsind GET-only (gridRequireGetRequest()) und normalisierenlimit/offset/order/dirüber Grid-Helper.
Einfaches ASCII-Beispiel
Beispiel: GET /admin/users/data
Browser
-> web/index.php (Bootstrap + AppContainer)
-> pages/admin/users/data().php (Action)
-> Guard + AuthorizationService (Auth/AuthZ)
-> UserAccountService (Fachlogik)
-> UserListQueryRepository (SQL + Filter + Paging)
-> DB
<- { data, total } JSON
Factory/Gateway im selben Bild:
AppContainer
-> UserServicesFactory
-> createUserAccountService() -> UserAccountService
Guard::requireAbilityOrForbidden(ops....)
-> app(AuthorizationService::class)
-> AccessPolicyFactory -> *AuthorizationPolicy
-> PermissionGateway -> PermissionService -> PermissionRepository -> DB
Front Controller (web/index.php)
-> app(UiAccessService::class)
-> UiCapabilityMap::LAYOUT -> $viewAuth['layout']
Action
-> app(UiAccessService::class)
-> UiCapabilityMap::* -> $viewAuth['page']
-> templates/** (nur Darstellung)
Absolute No-Go's
- SQL in View-Dateien
- Business-Logik in Actions
- Tenant-Scope als UI-Only-Check
Vertiefung
- Vollständiger Kompass:
/docs/explanation-architektur.md - Regeln für
core/**:/docs/reference-core-standards.md - RBAC-Rechte erweitern:
/docs/howto-rbac-permissions-playbook.md