# Bounded Context Map

Zwei Beziehungsarten zwischen den Modulen: durchgezogene Pfeile sind synchrone Maven-/Java-
Abhängigkeiten (Application-Service-Interfaces, siehe ADR-0001), gestrichelte Pfeile sind
asynchrone Kafka-Events über die Transactional Outbox (siehe ADR-0003). Quelle für die
synchronen Kanten: `<dependency>`-Einträge in den jeweiligen `pom.xml`-Dateien.

```mermaid
graph LR
    Common["procurex-common<br/>Shared Kernel"]

    Supplier["procurex-supplier<br/>PRX-3"]
    Catalog["procurex-catalog<br/>PRX-4"]
    Requisition["procurex-requisition<br/>PRX-2"]
    Ordering["procurex-ordering<br/>PRX-2, PRX-5, PRX-8, PRX-12"]
    Approval["procurex-approval<br/>PRX-5, PRX-8"]
    Receiving["procurex-receiving<br/>PRX-10"]
    Invoicing["procurex-invoicing<br/>PRX-11, PRX-9"]
    Audit["procurex-audit<br/>PRX-34"]
    Notification["procurex-notification"]

    Common -.-> Supplier
    Common -.-> Catalog
    Common -.-> Requisition
    Common -.-> Ordering
    Common -.-> Approval
    Common -.-> Receiving
    Common -.-> Invoicing
    Common -.-> Audit
    Common -.-> Notification

    Requisition --> Supplier
    Requisition --> Catalog
    Requisition --> Ordering
    Ordering --> Supplier
    Approval --> Ordering
    Receiving --> Ordering
    Invoicing --> Ordering
    Invoicing --> Receiving
    Notification -->|"UC-07: findPendingApprovalIdsOlderThan"| Ordering

    Ordering -.->|order-submitted.v1| Approval
    Approval -.->|order-approved.v1 / order-rejected.v1| Ordering
    Receiving -.->|goods-received.v1| Invoicing
    Invoicing -.->|invoice-matched.v1 / invoice-discrepancy-flagged.v1| Notification
    Ordering -.->|order-submitted.v1| Audit
    Approval -.->|order-approved/rejected.v1| Audit
    Receiving -.->|goods-received.v1| Audit
    Invoicing -.->|invoice-matched/discrepancy.v1| Audit
    Ordering -.->|order-submitted.v1| Notification
    Approval -.->|order-approved/rejected.v1| Notification
    Receiving -.->|goods-received.v1| Notification
```

## Beziehungstypen im Detail

| Von | Nach | Art | Zweck |
|---|---|---|---|
| requisition | supplier, catalog, ordering | synchron (Maven) | Warenkorb validieren, in Bestellung überführen |
| ordering | supplier | synchron (Maven) | Lieferantenstatus für Bestellverfolgung (PRX-12) |
| approval | ordering | synchron (Maven) | Bestellstatus bei Genehmigungsentscheidung setzen |
| receiving | ordering | synchron (Maven) | Wareneingang einer Bestellung zuordnen |
| invoicing | ordering, receiving | synchron (Maven) | 3-Way-Match: Rechnung ↔ Bestellung ↔ Wareneingang |
| ordering → approval/receiving/invoicing/audit/notification | asynchron (Kafka Outbox) | Entkopplung entlang der Prozesskette |
| audit, notification | (alle publizierenden Module) | asynchron (Kafka, reine Konsumenten) | Querschnittsfunktionen ohne Rückkopplung auf die Fachmodule |
| notification → ordering | synchron (Maven) | UC-07: periodische Abfrage überfälliger `PENDING_APPROVAL`-Bestellungen (kein Kafka-Event dafür, da es kein Ereignis, sondern reines Zeitablauf-Polling ist) |

**Korrektur 2026-08-17 (UC-07):** Diese Seite behauptete zuvor eine durchgängige Asymmetrie —
`procurex-audit` und `procurex-notification` hätten *keine* Maven-Abhängigkeit auf Fachmodule.
Das stimmt weiterhin für `procurex-audit` (bleibt rein event-getrieben), aber nicht mehr für
`procurex-notification`: die Fristüberwachung (UC-07, `OverdueApprovalNotifier`) braucht eine
aktive Abfrage statt eines Events und hat dafür eine gezielte, schmale Abhängigkeit auf
`procurex-ordering` über `OrderLookupPort` bekommen — weiterhin **keine** direkte
Schemazugriff, nur die öffentliche Port-Schnittstelle. Details: `procurex-notification/README.md`.