V13-FE-006: consolidate approved UI and contract hardening
This commit is contained in:
+22
@@ -0,0 +1,22 @@
|
||||
# Backend integration notes
|
||||
|
||||
## FastEndpoints validation contract
|
||||
|
||||
Register the KBX validation response builder when configuring FastEndpoints:
|
||||
|
||||
```csharp
|
||||
app.UseFastEndpoints(c =>
|
||||
{
|
||||
KbxFastEndpoints.ConfigureErrors(c);
|
||||
});
|
||||
```
|
||||
|
||||
This keeps automatic FluentValidation failures aligned with the frontend `KbxValidationProblem` contract. Row-specific validation remains inside the application handler because a stable UI `rowKey` (`ClientId`) is more useful than an array index such as `Lines[7]`.
|
||||
|
||||
## DbUp
|
||||
|
||||
Run `backend/Database/Migrations/20260808_001_oms_order_golden_screen.sql` through the application's normal DbUp pipeline. The migration is intentionally self-contained for the starter; a production modular monolith should retain schema/table ownership within each module and reference contracts rather than centralizing business tables in a shared module.
|
||||
|
||||
## Transaction boundary
|
||||
|
||||
`RegisterOrderHandler` keeps order header, order lines, audit record and outbox message in one PostgreSQL transaction. External integration dispatch is explicitly outside that transaction.
|
||||
Reference in New Issue
Block a user