438040acce
Vier-Crate-Workspace mit:
- Domain: Account, Car, Tour, Delivery, DeliveryItem, DeliveryNote, Customer,
Article, Warehouse, ScanState, AuditAction — alle mit serde + feature-gated
utoipa::ToSchema.
- Application: Ports (TourRepository, DeliveryRepository, ScanRepository,
DeliveryNoteRepository, CarRepository, AuthService) und Use Cases.
- Infrastructure: Postgres-Adapter via sqlx (PgTourRepository etc.) +
Keycloak-AuthService mit JWKS-Cache + OIDC-Discovery.
- API: Axum 0.8, utoipa-OpenAPI + Swagger-UI, JWT-Bearer-Middleware,
AuthenticatedUser-Extractor.
Endpoints:
- GET /me/tours/today, /tours/{id}, /accounts/{pn}, /me/cars, /health
- POST /sync/tour, /scans (bulk + idempotent via clientScanId),
/deliveries/{id}/{hold,resume,cancel,complete,notes}, /me/cars
- PUT /tours/{id}/delivery-order, /deliveries/{id}/assigned-car, /me/cars/{id}
- PATCH /me/cars/{id}
Datenmodell:
- 6 Migrationen (accounts, tours/deliveries/items + Stammdaten,
scan_audit mit clientScanId-UNIQUE, state_reason refactor,
delivery_notes, cars + FKs nachziehen).
- Business-stabile Beleg-Keys (belegart_id, belegnummer) für ERP-Sync.
- Append-only scan_audit + embedded scan_state als doppelte Wahrheit.
Dev-Setup:
- docker-compose mit Postgres 17 + Keycloak 26
- Keycloak-Realm 'holzleitner' mit Public-Client (PKCE), Testfahrer
(PN 1001) + Audience-/Personalnummer-Mapper
39 lines
1.3 KiB
Rust
39 lines
1.3 KiB
Rust
//! Domänenmodell des Lieferservice-Backends.
|
|
//!
|
|
//! Aufbau pro Aggregat-Wurzel bzw. zusammengehöriger Begriffsgruppe.
|
|
//! Reihenfolge der Module entspricht inhaltlich der Datenfluss-Logik:
|
|
//! Stamm- und Strukturdaten zuerst, danach transaktionale Aggregate
|
|
//! (Tour → Delivery → Audit), zuletzt der prozessuale Zustand.
|
|
//!
|
|
//! **Konventionen**
|
|
//! * Rust-Felder in `snake_case`, JSON via `serde` in `camelCase`.
|
|
//! * Enum-Varianten in `PascalCase`, JSON via `serde` in `snake_case`.
|
|
//! * Identifier vom ERP (Personalnummer, Belegart/-nummer, Artikelnummer)
|
|
//! behalten ihre fachlichen Namen, weil sie als Brücken im Datenmodell
|
|
//! erkennbar bleiben sollen.
|
|
//! * Eigene IDs sind UUIDs — entkoppelt vom ERP, generieren wir selbst.
|
|
|
|
#![allow(dead_code)] // Modelle werden später von Service-Schicht genutzt.
|
|
|
|
mod account;
|
|
mod article;
|
|
mod audit;
|
|
mod car;
|
|
mod common;
|
|
mod customer;
|
|
mod delivery;
|
|
mod process_state;
|
|
mod tour;
|
|
mod warehouse;
|
|
|
|
pub use account::Account;
|
|
pub use article::Article;
|
|
pub use audit::{AuditAction, ScanAuditEntry};
|
|
pub use car::Car;
|
|
pub use common::Address;
|
|
pub use customer::{Customer, CustomerContact};
|
|
pub use delivery::{Delivery, DeliveryItem, DeliveryNote, DeliveryState, ScanState, ScanStatus};
|
|
pub use process_state::{DeliveryPhase, DeliveryProcessState};
|
|
pub use tour::Tour;
|
|
pub use warehouse::Warehouse;
|