Why should you care?

ShopNest orders link Customer, shipping address snapshot, payments, and items — real models rarely stop at simple one-to-many.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

public class Order
{
    public int Id { get; set; }
    public int CustomerId { get; set; }
    public Customer Customer { get; set; } = null!;
    public Address ShipTo { get; set; } = new(); // owned type
    public ICollection<OrderItem> Items { get; set; } = new();
    public ICollection<Payment> Payments { get; set; } = new();
}

modelBuilder.Entity<Order>().OwnsOne(o => o.ShipTo);
modelBuilder.Entity<OrderItem>()
    .HasOne(i => i.Product).WithMany().HasForeignKey(i => i.ProductId);

What happened?

• OwnsOne embeds ShipTo columns on Orders table.
• Order links Customer (many-to-one), Items (one-to-many), Payments (one-to-many) simultaneously.

Practice next

1. Draw ER diagram before Fluent API.
2. Configure each relationship explicitly in complex areas.
3. Split bounded contexts if graph becomes unwieldy.
4. Add Payment many-to-one Order with optional partial payments.
5. Map inheritance hierarchy for Product types — TPH vs TPT.

Remember

Real domains mix relationship types. Owned types embed value objects. Explicit Fluent config prevents convention surprises.

ShopNest checkout model

Order aggregates owned ShipTo address, line items, and payment attempts.

Outcome: Single SaveChanges persists coherent checkout graph matching business document.