Rich domain model or anemic domain model: what is the difference, what problems does an anemic model cause, and how would you move a .NET codebase towards a richer model without over-engineering it?

1. Domain-driven design building blocks (just enough)

• Entity: identity + lifecycle; behaviour and invariants (Order).
• Value object: immutable, compared by value, validates itself (Money).
• Aggregate: a consistency boundary with a root entity; all changes go through the root; other aggregates referenced by ID.
• Domain event: an immutable record of something that happened (OrderShipped), raised by the aggregate and dispatched after saving.
• Domain service: stateless logic that doesn't belong to one entity (e.g. pricing involving multiple aggregates).
• Application service / handler: orchestrates use cases: load, call domain methods, persist, publish.

A rich model uses these selectively.

2. Tell, Don't Ask

Anemic code asks for data and decides elsewhere:

if (order.Status == OrderStatus.Paid && order.Lines.Count > 0) { order.Status = OrderStatus.Shipped; }

Rich code tells the object what to do and lets it decide:

order.Ship(clock.GetUtcNow());

This keeps decisions next to the data they depend on (information expert principle, GRASP).

3. EF Core support for rich models

builder.Property(o => o.Status).HasConversion<string>();
builder.Navigation(o => o.Lines).HasField("_lines").UsePropertyAccessMode(PropertyAccessMode.Field);
builder.ComplexProperty(o => o.ShippingAddress);
builder.HasKey(o => o.Id);
builder.Property(o => o.Id).HasConversion(id => id.Value, v => new OrderId(v));

• Private parameterless constructor for materialisation.
• Private setters and backing fields.
• Value conversions for strongly typed IDs and value objects.
• SaveChanges interceptor to dispatch domain events after commit (or an outbox for reliability).

4. Testing a rich model

Domain tests become plain unit tests — no mocks, no database:

[Fact]
public void Cannot_ship_unpaid_order()
{
    var order = OrderMother.Draft();
    var act = () => order.Ship(DateTimeOffset.UtcNow);
    act.Should().Throw<InvalidOrderStateException>();
}

Application-layer tests cover orchestration (with fakes or real infrastructure via Testcontainers).

5. Transaction script vs domain model

Fowler's patterns: Transaction Script (procedural service per use case) is simple and fine for little logic; Domain Model pays off as rules grow. Many systems mix them: rich model in the complex core domain (billing, pricing), transaction scripts in simple supporting areas (admin CRUD). DDD calls this distinguishing core from supporting and generic subdomains.

6. Common objections and answers

• "Entities shouldn't depend on time/services." → pass values (DateTimeOffset at) or policies as method parameters; keep I/O out.
• "EF Core needs public setters." → it doesn't; use private setters/backing fields.
• "Serialisation needs public properties." → serialise DTOs, not entities.
• "It's more code." → less duplicated logic overall; tests become simpler.

Try it yourself

1. Pick one property with a public setter changed from multiple places; make the setter private and add a method; fix the compile errors.
2. Introduce a Money value object and replace decimal in one aggregate.
3. Map a private collection with EF Core backing fields.
4. Write domain unit tests for the new methods without any mocks.

public sealed class Subscription
{
    private readonly List<DomainEvent> _events = [];
    private Subscription() { }                                  // EF Core

    public Guid Id { get; private set; }
    public SubscriptionStatus Status { get; private set; }
    public DateOnly PaidUntil { get; private set; }
    public Money Price { get; private set; } = default!;
    public IReadOnlyList<DomainEvent> Events => _events;

    public static Subscription Start(Money price, DateOnly today) =>
        new() { Id = Guid.CreateVersion7(), Status = SubscriptionStatus.Active, Price = price, PaidUntil = today.AddMonths(1) };

    public void Renew(TimeProvider clock)
    {
        if (Status == SubscriptionStatus.Cancelled)
            throw new DomainException("A cancelled subscription cannot be renewed");
        var today = DateOnly.FromDateTime(clock.GetUtcNow().UtcDateTime);
        if (PaidUntil > today.AddDays(7)) return;                // not due yet
        PaidUntil = PaidUntil.AddMonths(1);
        _events.Add(new SubscriptionRenewed(Id, Price, PaidUntil));
    }

    public void Cancel()
    {
        if (Status == SubscriptionStatus.Cancelled) return;      // idempotent
        Status = SubscriptionStatus.Cancelled;
        _events.Add(new SubscriptionCancelled(Id));
    }
}

// Thin application service: orchestration only
public sealed class RenewSubscriptionsJob(AppDb db, TimeProvider clock, IPaymentGateway payments)
{
    public async Task RunAsync(CancellationToken ct)
    {
        var due = await db.Subscriptions
            .Where(s => s.Status == SubscriptionStatus.Active)
            .ToListAsync(ct);
        foreach (var s in due) s.Renew(clock);                   // the rule lives in ONE place
        await db.SaveChangesAsync(ct);                           // events dispatched by an interceptor
    }
}

// Unit test: no database, no mocks except time
[Fact]
public void Cancelled_subscription_cannot_be_renewed()
{
    var s = Subscription.Start(new Money(20, "AUD"), new DateOnly(2026, 1, 1));
    s.Cancel();
    Assert.Throws<DomainException>(() => s.Renew(new FakeTimeProvider(new DateTimeOffset(2026, 1, 30, 0, 0, 0, TimeSpan.Zero))));
}