//! 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;