DBOs and the DbContext

A DBO (database object) is the class EF maps to a table. It’s a plain data holder: properties for columns, attributes for constraints. It’s deliberately separate from the domain model, which is why the query store maps a DBO row into a domain DTO rather than handing the DBO out. The DBO knows about the database; the domain doesn’t.

public record FlightDisruptionCostCalc : IAuditableDbo
{
    public int Id { get; set; }                          // EF makes Id the primary key by convention
    [MaxLength(10)] public string FlightNumber { get; set; } = string.Empty;
    [MaxLength(100)] public string EjdpUniqueFlightKey { get; set; } = string.Empty;
    [Column(TypeName = "decimal(12,2)")] public decimal CrewHotacCost { get; set; }
    public DateTime? DecidedAtUtc { get; set; }          // nullable column
    // audit columns (CreatedBy, etc.) come from IAuditableDbo, filled by Postgres defaults
}

The DbContext is the schema and the entry point for queries: it exposes a DbSet<T> per table, and it’s where model configuration lives. Fusion uses EFCore.NamingConventions so C# FlightNumber becomes SQL flight_number automatically. That’s why the migration you’ll read in a moment says flight_disruption_cost_calcs, snake_case, without anyone writing that mapping by hand.