PROCUREX — B2B Procurement Platform

Fiktives Lernprojekt: eine Beschaffungsplattform (Procure-to-Pay), umgesetzt als modularer

Spring-Boot-Monolith. Projektsteuerung läuft über Jira (PRX auf aydinsude.atlassian.net) und

Confluence (PRX auf aydinsude.atlassian.net/wiki). Dauerhafte Architektur- und

Technologieentscheidungen stehen in PROCUREX-PLANUNGSENTSCHEIDUNGEN.md; der aktuelle

Repository- und Teststatus wird in dieser README und in project.yaml gepflegt.

Projektstatus

• Lebenszyklus: stabiler, abgeschlossener Lernstand; produktionsnahe Erweiterungen bleiben bewusst optional
• Zuletzt verifiziert: 10.09.2026 mit 46 Standard-, 5 PostgreSQL-Integrations- und 2 Frontend-Tests sowie Angular-Produktionsbuild
• Kanonischer Pfad: projects/procurex-platform
• Filterbare Metadaten: project.yaml enthält Status, Tags, Qualitätsstand, Testzahlen, Einstiegspunkte und Beziehungen
• Reproduzierbarer Gesamtcheck: pwsh -NoProfile -File scripts/test-all.ps1

Architektur

Modularer Monolith (ein deploybares Artefakt procurex-app), Module nach Bounded Context getrennt,

jedes mit eigenem PostgreSQL-Schema und öffentlichen Port-Interfaces für modulübergreifende Aufrufe

(kein direkter Zugriff auf fremde Schemas). Details: Confluence Seite 09 „Zielarchitektur und

Modulstruktur“.

procurex-platform (Parent-POM)
├── procurex-common       Shared Kernel (Exceptions, Problem-Details, Correlation-ID, Money)
├── procurex-supplier     Lieferantenverwaltung          PRX-3
├── procurex-catalog      Produktkatalog                 PRX-4
├── procurex-requisition  Warenkorb absenden              PRX-2
├── procurex-ordering     Bestellung (Kernaggregat)       PRX-2, PRX-5, PRX-8, PRX-12
├── procurex-approval     Genehmigung                     PRX-5, PRX-8
├── procurex-receiving    Wareneingang                    PRX-10
├── procurex-invoicing    Rechnungsprüfung (3-Way-Match)   PRX-11, PRX-9
└── procurex-app          Spring-Boot-Bootstrap-Modul

procurex-frontend         Angular-22-SPA (Standalone Components)         PRX-20

Jedes Modul hat ein eigenes README.md mit Endpunkten und Geschäftsregeln.

Benachrichtigungen sind im aktuellen Release bewusst abgegrenzt: Der Frontend-

NotificationService erzeugt nur lokale UI-Meldungen. Ein fachliches E-Mail-/Webhook-/Kafka-

Benachrichtigungsmodul ist noch nicht implementiert; die Entscheidung und der spätere

Umsetzungsschnitt stehen in docs/notification-scope.md.

Tech-Stack (bestätigt, siehe Confluence Seite 08)

Java 17 LTS · Spring Boot 3.3.4 · Maven Multi-Module · PostgreSQL 16 · Flyway · Angular ^22 ·

Keycloak 26.7.0 · Kafka (Confluent 7.7.1) — Anbindung an die geteilte lokale Plattform

enterprise-infrastructure (Netzwerk proxy, Hostname-Präfix procurex).

Build & Test

mvn test

Der Maven-Reactor läuft standardmäßig parallel (.mvn/maven.config, -T 1C). Das ist bei diesem

11-Modul-Projekt wichtig, weil die unabhängigen Module und ihre Surefire-Testläufe sonst seriell

gestartet werden. Eine Messung auf dem lokalen Windows-Rechner mit warmem Maven-Cache ergab:

Die Verbesserung beträgt in dieser Umgebung rund 32 %. Die Zeit ist hardware- und cacheabhängig.

Der Hauptgrund für den ursprünglichen langsamen Eindruck war nicht die Contract-Generierung,

sondern der serielle Reactor mit mehreren modulweisen Surefire-Teststarts. Die Contract-Tests

werden nur im Modul procurex-app generiert und waren im Messlauf bereits aktuell.

Der Standardlauf benötigt keine laufende Datenbank oder Docker, weil die drei

Testcontainers-Integrationstests standardmäßig ausgeschlossen sind. Sie werden separat gegen

eine Docker-kompatible Engine ausgeführt. Lokal funktioniert das mit einer gestarteten Podman-

Machine:

podman machine start podman-machine-default
$env:TESTCONTAINERS_RYUK_DISABLED = 'true'
mvn -pl procurex-app -am test "-Dprocurex.integration=true" "-Ddocker.host=npipe:////./pipe/docker_engine"

Damit ist klar getrennt zwischen schnellem Standard-Quality-Gate und den teureren Tests mit echter

PostgreSQL-Instanz. Die Integrationstest-Ausnahme ist in procurex-app/pom.xml dokumentiert; der

separate Lauf ist ein echter Datenbankintegrationsnachweis.

Anwendung starten

Lokal (Maven/ng serve): Backend siehe procurex-app/README.md, Frontend siehe

procurex-frontend/README.md.

Docker (PRX-21): docker-compose.yml im Repo-Root containerisiert Backend und Frontend und

bindet sie über das externe proxy-Netzwerk an den zentralen Traefik aus enterprise-infrastructure an –

erreichbar unter http://procurex.localhost (Frontend) und http://procurex-api.localhost

(Backend). End-to-end getestet: Flyway-Migrationen laufen gegen die geteilte Postgres-Instanz

(procurex_db), CORS-Preflight von procurex.localhost funktioniert. Details und Startreihenfolge:

procurex-app/README.md, Abschnitt „Starten – Docker“.

Sprintübersicht

Die ursprüngliche Planung umfasste vier Sprints. Für die inzwischen vorhandenen Integrations-,

Betriebs- und Quality-Artefakte wurden nachträglich zwei provisorische Lernprojekt-Sprints

dokumentiert:

Die dauerhaften technischen Nachweise stehen bei den jeweiligen Quellen: in Jenkinsfile, docs/quality-gates.md, loadtests/README.md, procurex-frontend/README.md und den Spring-Cloud-Contract-Verträgen.

Umgesetzte Tickets (Sprint 1–6)

Der aktuelle E2E-Nachweis umfasst 4/4 Playwright-Tests. Der aktuelle k6-Lauf gegen Podman/

enterprise-infrastructure lief für alle drei Szenarien mit 0 % Fehlern und erfüllten Latenz-Thresholds;

Details stehen in loadtests/README.md.

Nicht Teil dieser Runde (siehe PROCUREX-PLANUNGSENTSCHEIDUNGEN.md): produktives Kubernetes-

Deployment (kein Cluster in dieser Lernumgebung verfügbar).