What is aggregation, and how does it differ from composition? Use examples to explain shared versus owned parts, lifetimes, deletion and cascade rules, and how the difference shows up in C# code and EF Core mappings.

1. UML definitions

• Aggregation (hollow diamond ◇): a whole–part association where the part can exist independently and be shared. UML itself treats aggregation as semantically weak — many modellers avoid it and just use association.
• Composition (filled diamond ◆): strong ownership; a part belongs to at most one whole at a time, and if the whole is destroyed, so are its parts (unless explicitly moved first).

In practice, the useful question is: "If I delete the whole, should the parts be deleted?" and "Can the part be referenced by anything else?"

2. DDD aggregates (a different use of "aggregate")

In domain-driven design, an aggregate is a cluster of objects treated as one unit for changes and consistency, with a single aggregate root (e.g. Order with its OrderLines). Internally that's composition; between aggregates, references are by ID, which is closer to UML aggregation/association. The naming collision causes confusion in interviews — worth clarifying.

Rules of thumb for aggregate design (Vaughn Vernon): keep aggregates small, reference other aggregates by ID, modify one aggregate per transaction, and use domain events for eventual consistency across aggregates.

3. EF Core delete behaviours

EF Core's defaults: required relationships default to Cascade; optional ones to ClientSetNull. So a non-nullable FK (e.g. int DepartmentId) silently gives you cascade — exactly the HR bug above. SQL Server also rejects multiple cascade paths, forcing explicit choices.

4. Orphan removal and owned types

• Removing a child from a tracked required collection makes it an orphan; EF Core deletes it on SaveChanges (configurable via DeleteOrphansTiming).
• Owned entity types (OwnsOne, OwnsMany): no DbSet, can't be queried independently, always loaded with the owner, stored in the owner's table (OwnsOne) or a separate table (OwnsMany).
• Complex types (EF Core 8+): value-object semantics with no identity, stored as columns of the owner; better for immutable value objects (records).

5. Soft deletes and aggregation

For aggregated parts with history (employees, customers), soft deletes (IsDeleted + global query filter) avoid destructive cascades and preserve audit trails. Composition parts usually go with their owner whether soft or hard deleted. Note: privacy obligations (APP 11 — destroy or de-identify personal information no longer needed) may require real deletion eventually; plan retention jobs.

6. Testing ownership rules

• Domain tests: removing a line from an order removes it from Lines and updates totals.
• Persistence tests (against a real SQL Server via Testcontainers): deleting an order deletes its lines; deleting a department with employees fails.
• Migration review: grep generated migrations for onDelete: ReferentialAction.Cascade.

Try it yourself

1. Map Department–Employee with a non-nullable FK and inspect the generated migration's onDelete.
2. Change to Restrict, try deleting a department with employees, and observe the error.
3. Model Order.Address as ComplexProperty and Order.Lines with OwnsMany, and compare tables.
4. Remove a line from a tracked order and check the SQL emitted on SaveChanges.

// Composition: Order owns its lines
public sealed class Order
{
    private readonly List<OrderLine> _lines = [];
    public Guid Id { get; } = Guid.NewGuid();
    public IReadOnlyList<OrderLine> Lines => _lines;

    public void AddLine(string sku, int quantity, decimal unitPrice)
    {
        if (_lines.Sum(l => l.Quantity) + quantity > 100)
            throw new InvalidOperationException("An order cannot exceed 100 items.");  // rule across parts
        _lines.Add(new OrderLine(sku, quantity, unitPrice));                           // created by the whole
    }
}

public sealed record OrderLine(string Sku, int Quantity, decimal UnitPrice);

// Aggregation: Team groups independent players by ID
public sealed class Team(string name)
{
    private readonly HashSet<Guid> _playerIds = [];
    public string Name { get; } = name;
    public IReadOnlyCollection<Guid> PlayerIds => _playerIds;

    public void Sign(Player player) => _playerIds.Add(player.Id);   // links an existing object
    public void Release(Player player) => _playerIds.Remove(player.Id);
}

public sealed class Player(string name)
{
    public Guid Id { get; } = Guid.NewGuid();
    public string Name { get; } = name;
}

// EF Core configuration showing the difference
public sealed class AppDb(DbContextOptions<AppDb> options) : DbContext(options)
{
    protected override void OnModelCreating(ModelBuilder b)
    {
        b.Entity<Order>().OwnsMany(o => o.Lines);            // composition: no DbSet<OrderLine>, deleted with order

        b.Entity<Employee>()
            .HasOne<Department>().WithMany()
            .HasForeignKey(e => e.DepartmentId)
            .OnDelete(DeleteBehavior.Restrict);              // aggregation: never cascade
    }
}

public sealed class Department { public int Id { get; set; } public string Name { get; set; } = ""; }
public sealed class Employee { public int Id { get; set; } public int? DepartmentId { get; set; } }