Building Rich Domain Models: A Practical Guide to DDD in .NET

Introduction

Have you ever found yourself lost in a maze of anemic domain models, where your business logic is scattered across services, and your entities are nothing more than data containers? If you're nodding along, you're not alone. Many .NET developers struggle with organizing complex business logic in a way that's both maintainable and reflects the real-world domain they're modeling.

Domain-Driven Design (DDD) offers a solution to this common problem. Rather than focusing on technical concerns first, DDD puts the business domain at the center of your application. It's not just a set of patterns—it's a way of thinking about software that aligns your code with the business reality it represents.

In this article, we'll dive deep into building rich domain models using .NET 9 and Clean Architecture principles. We'll use a real banking microservice as our example, showing you how to create entities that aren't just data holders, but intelligent objects that protect their own integrity and encapsulate business behavior.

By the end of this piece, you'll understand how to build domain models that business experts can relate to, developers can maintain, and that actually model the complexities of real-world business scenarios.

What Makes a Domain Model "Rich"?

Before we jump into code, let's understand what distinguishes a rich domain model from its anemic counterpart. An anemic domain model is essentially a collection of getters and setters with little to no business logic—the kind of code that makes you question whether you're building a business application or a simple CRUD system.

A rich domain model, on the other hand, encapsulates business rules, maintains its own consistency, and provides meaningful operations that reflect how the business actually works. Think of it this way: if you show your domain code to a business expert, they should be able to understand what's happening without needing a computer science degree.

Core Building Blocks of DDD

In DDD, we work with several key building blocks:

• Entities: Objects with a distinct identity that threads through time and different states
• Value Objects: Objects that describe characteristics but have no conceptual identity
• Aggregate Roots: Entities that serve as entry points to aggregates and maintain consistency boundaries
• Domain Events: Objects that capture something significant that happened in the domain
• Domain Services: Operations that don't naturally fit within an entity or value object

Let's see how these concepts come together in a practical banking scenario.

Building the Account Aggregate: A Real-World Example

Let's start with the foundation of our banking domain—the Account aggregate. In traditional applications, you might see something like this:

// ❌ Anemic model - just data with no behavior
public class Account
{
    public Guid Id { get; set; }
    public string AccountNumber { get; set; }
    public decimal Balance { get; set; }
    public string Status { get; set; }
    public Guid CustomerId { get; set; }
}

This approach forces business logic into service classes, making it hard to ensure consistency and scattered across multiple places. Instead, let's build a rich domain model that encapsulates the real behavior of a bank account.

Creating the Account Entity

Here's how we can model an Account as a rich domain entity:

using BankSystem.Shared.Domain.Common;
using BankSystem.Shared.Domain.ValueObjects;

namespace BankSystem.Account.Domain.Entities;

/// <summary>
/// Represents a bank account aggregate root in the banking domain.
/// An account is the primary entity for managing customer finances and transactions.
/// </summary>
public class Account : AggregateRoot<Guid>
{
    /// <summary>
    /// Gets the unique account number for this account.
    /// </summary>
    public AccountNumber AccountNumber { get; } = null!;

    /// <summary>
    /// Gets the customer who owns this account.
    /// </summary>
    public Guid CustomerId { get; }

    /// <summary>
    /// Gets the current balance of the account.
    /// </summary>
    public Money Balance { get; private set; } = null!;

    /// <summary>
    /// Gets the current status of the account.
    /// </summary>
    public AccountStatus Status { get; private set; }

    /// <summary>
    /// Gets the type of account (Checking, Savings, etc.).
    /// </summary>
    public AccountType Type { get; private set; }

    /// <summary>
    /// Gets the date and time when the account was closed (if applicable).
    /// </summary>
    public DateTime? ClosedAt { get; private set; }

    // Private constructor for EF Core
    private Account() { }

    /// <summary>
    /// Private constructor that ensures accounts are created through factory methods
    /// </summary>
    private Account(
        AccountNumber accountNumber,
        Guid customerId,
        AccountType type,
        Currency currency)
    {
        Guard.AgainstNullOrEmpty(accountNumber, nameof(accountNumber));
        Guard.AgainstNullOrEmpty(currency, nameof(currency));
        Guard.AgainstEmptyGuid(customerId, nameof(customerId));

        Id = Guid.NewGuid();
        AccountNumber = accountNumber;
        CustomerId = customerId;
        Type = type;
        Balance = Money.Zero(currency);
        Status = AccountStatus.PendingActivation;
    }

    /// <summary>
    /// Factory method to create a new account for a customer.
    /// This is the only way to create a new account, ensuring all business rules are followed.
    /// </summary>
    public static Account CreateNew(Guid customerId, AccountType type, Currency currency)
    {
        var accountNumber = AccountNumber.Generate();
        var account = new Account(accountNumber, customerId, type, currency);

        // Raise domain event - this is important for event-driven architecture
        account.AddDomainEvent(
            new AccountCreatedEvent(
                account.Id,
                customerId,
                account.AccountNumber,
                type.ToString(),
                DateTime.UtcNow
            )
        );

        return account;
    }

    /// <summary>
    /// Business operation: Activates the account
    /// Notice how business rules are encapsulated within the entity
    /// </summary>
    public Result Activate()
    {
        if (Status == AccountStatus.Active)
            return Result.Failure("Account is already active");

        if (Status == AccountStatus.Closed)
            return Result.Failure("Cannot activate a closed account");

        Status = AccountStatus.Active;

        AddDomainEvent(
            new AccountActivatedEvent(Id, CustomerId, AccountNumber.Value, DateTime.UtcNow)
        );

        return Result.Success();
    }

    /// <summary>
    /// Business operation: Suspends the account with business logic validation
    /// </summary>
    public Result Suspend(string reason)
    {
        Guard.AgainstNullOrEmpty(reason, nameof(reason));

        if (Status == AccountStatus.Closed)
            return Result.Failure("Cannot suspend a closed account");

        Status = AccountStatus.Suspended;

        AddDomainEvent(new AccountSuspendedEvent(Id, reason, DateTime.UtcNow));
        return Result.Success();
    }

    /// <summary>
    /// Business operation: Closes the account with business constraints
    /// </summary>
    public Result Close(string reason)
    {
        Guard.AgainstNullOrEmpty(reason, nameof(reason));

        if (Status == AccountStatus.Closed)
            return Result.Failure("Account is already closed");

        // Business rule: Cannot close account with outstanding balance
        if (!Balance.IsZero)
            return Result.Failure("Cannot close account with non-zero balance");

        Status = AccountStatus.Closed;
        ClosedAt = DateTime.UtcNow;

        AddDomainEvent(new AccountClosedEvent(Id, AccountNumber, CustomerId, reason));
        return Result.Success();
    }

    /// <summary>
    /// Business operation: Processes a deposit transaction
    /// </summary>
    public Result<Transaction> Deposit(Money amount, string description, string reference)
    {
        if (Status != AccountStatus.Active)
            return Result<Transaction>.Failure("Account must be active to process deposits");

        if (amount.Amount <= 0)
            return Result<Transaction>.Failure("Deposit amount must be positive");

        if (amount.Currency != Balance.Currency)
            return Result<Transaction>.Failure("Currency mismatch");

        Balance = Balance.Add(amount);

        var transaction = Transaction.CreateDeposit(Id, amount, description, reference);

        AddDomainEvent(new DepositProcessedEvent(Id, amount, Balance, transaction.Id));

        return Result<Transaction>.Success(transaction);
    }

    /// <summary>
    /// Business operation: Processes a withdrawal with overdraft protection
    /// </summary>
    public Result<Transaction> Withdraw(Money amount, string description, string reference)
    {
        if (Status != AccountStatus.Active)
            return Result<Transaction>.Failure("Account must be active to process withdrawals");

        if (amount.Amount <= 0)
            return Result<Transaction>.Failure("Withdrawal amount must be positive");

        if (amount.Currency != Balance.Currency)
            return Result<Transaction>.Failure("Currency mismatch");

        // Business rule: Overdraft protection
        if (Balance.Amount < amount.Amount)
            return Result<Transaction>.Failure("Insufficient funds");

        Balance = Balance.Subtract(amount);

        var transaction = Transaction.CreateWithdrawal(Id, amount, description, reference);

        AddDomainEvent(new WithdrawalProcessedEvent(Id, amount, Balance, transaction.Id));

        return Result<Transaction>.Success(transaction);
    }
}

Notice how this entity is vastly different from our anemic example. It:

1. Protects its invariants: Private setters and factory methods ensure the object is always in a valid state
2. Encapsulates business logic: Operations like Activate(), Suspend(), and Close() contain the actual business rules
3. Communicates intent: Method names reflect business operations, not just data manipulation
4. Publishes domain events: When important business events occur, the entity announces them

Value Objects: The Building Blocks of Rich Models

Value objects are crucial for creating expressive domain models. They represent concepts that have no identity but are important to the domain. Let's look at two key value objects in our banking domain:

AccountNumber Value Object

namespace BankSystem.Account.Domain.ValueObjects;

/// <summary>
/// Represents a bank account number with validation and formatting logic.
/// This is a value object - it has no identity, just value.
/// </summary>
public record AccountNumber
{
    private const int AccountNumberLength = 10;
    private static readonly Random Random = new();
    private static readonly Lock RandomLock = new();

    public string Value { get; }

    public AccountNumber(string value)
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new DomainException("Account number cannot be null or empty");

        var cleanValue = value.Trim();

        if (!IsValidFormat(cleanValue))
            throw new DomainException($"Invalid account number format: {value}. Expected 10 digits");

        Value = cleanValue;
    }

    /// <summary>
    /// Factory method to generate a new unique account number
    /// This encapsulates the business logic of how account numbers are created
    /// </summary>
    public static AccountNumber Generate()
    {
        var digits = new char[AccountNumberLength];

        lock (RandomLock)
        {
            for (var i = 0; i < AccountNumberLength; i++)
            {
                digits[i] = (char)('0' + Random.Next(0, 10));
            }
        }

        return new AccountNumber(new string(digits));
    }

    /// <summary>
    /// Validates the account number format according to business rules
    /// </summary>
    private static bool IsValidFormat(string value)
    {
        return value.Length == AccountNumberLength &&
               value.All(char.IsDigit);
    }

    /// <summary>
    /// Provides formatted display for different contexts
    /// </summary>
    public string ToFormattedString()
    {
        return $"{Value[..3]}-{Value[3..6]}-{Value[6..]}";
    }

    // Record types automatically provide value-based equality
    public override string ToString() => Value;

    // Implicit conversion for convenience
    public static implicit operator string(AccountNumber accountNumber) => accountNumber.Value;
}

Money Value Object

namespace BankSystem.Shared.Domain.ValueObjects;

/// <summary>
/// Represents monetary amounts with currency information.
/// This prevents mixing currencies and provides financial operations.
/// </summary>
public record Money
{
    public decimal Amount { get; init; }
    public Currency Currency { get; init; }

    // Private constructor for EF Core
    private Money() { }

    public Money(decimal amount, Currency currency)
    {
        ArgumentNullException.ThrowIfNull(currency);

        // Enforce currency precision rules
        if (decimal.Round(amount, currency.DecimalPlaces) != amount)
            throw new DomainException($"Amount has too many decimal places for currency {currency.Code}");

        Amount = amount;
        Currency = currency;
    }

    public static Money Zero(Currency currency) => new(0, currency);

    /// <summary>
    /// Adds two Money values. Both must have the same currency.
    /// This business rule is enforced at the domain level.
    /// </summary>
    public Money Add(Money other)
    {
        if (!Currency.Equals(other.Currency))
            throw new DomainException($"Cannot add {Currency.Code} to {other.Currency.Code}");

        return new Money(Amount + other.Amount, Currency);
    }

    /// <summary>
    /// Subtracts two Money values with currency validation
    /// </summary>
    public Money Subtract(Money other)
    {
        if (!Currency.Equals(other.Currency))
            throw new DomainException($"Cannot subtract {other.Currency.Code} from {Currency.Code}");

        return new Money(Amount - other.Amount, Currency);
    }

    /// <summary>
    /// Multiplies money by a factor (useful for interest calculations)
    /// </summary>
    public Money Multiply(decimal factor)
    {
        return new Money(Amount * factor, Currency);
    }

    /// <summary>
    /// Business method to check if the amount is zero
    /// </summary>
    public bool IsZero => Amount == 0;

    /// <summary>
    /// Business method to check if the amount is positive
    /// </summary>
    public bool IsPositive => Amount > 0;

    /// <summary>
    /// Business method to check if the amount is negative
    /// </summary>
    public bool IsNegative => Amount < 0;

    /// <summary>
    /// Formatted string representation for display
    /// </summary>
    public override string ToString()
    {
        return $"{Amount:C} {Currency.Code}";
    }
}

Domain Events: Capturing What Happened

Domain events are crucial for building event-driven systems and maintaining loose coupling between bounded contexts. They represent something significant that happened in the domain.

namespace BankSystem.Account.Domain.Events;

/// <summary>
/// Domain event raised when a new account is created.
/// This allows other parts of the system to react to account creation.
/// </summary>
public record AccountCreatedEvent(
    Guid AccountId,
    Guid CustomerId,
    AccountNumber AccountNumber,
    string AccountType,
    DateTime CreatedAt) : IDomainEvent
{
    public Guid Id { get; } = Guid.NewGuid();
    public DateTime OccurredOn { get; } = DateTime.UtcNow;
}

/// <summary>
/// Domain event for account activation
/// </summary>
public record AccountActivatedEvent(
    Guid AccountId,
    Guid CustomerId,
    string AccountNumber,
    DateTime ActivatedAt) : IDomainEvent
{
    public Guid Id { get; } = Guid.NewGuid();
    public DateTime OccurredOn { get; } = DateTime.UtcNow;
}

/// <summary>
/// Domain event for deposit transactions
/// </summary>
public record DepositProcessedEvent(
    Guid AccountId,
    Money Amount,
    Money NewBalance,
    Guid TransactionId) : IDomainEvent
{
    public Guid Id { get; } = Guid.NewGuid();
    public DateTime OccurredOn { get; } = DateTime.UtcNow;
}

The Aggregate Root Pattern

The AggregateRoot base class provides the infrastructure for handling domain events:

namespace BankSystem.Shared.Domain.Common;

/// <summary>
/// Base class for aggregate roots that manage domain events
/// </summary>
public abstract class AggregateRoot<TId> : Entity<TId>
{
    private readonly List<IDomainEvent> _domainEvents = [];

    /// <summary>
    /// Domain events produced by this aggregate.
    /// These will be published after successful persistence.
    /// </summary>
    public IReadOnlyCollection<IDomainEvent> DomainEvents => _domainEvents.AsReadOnly();

    /// <summary>
    /// Adds a domain event to be published later
    /// </summary>
    protected void AddDomainEvent(IDomainEvent domainEvent)
    {
        _domainEvents.Add(domainEvent);
    }

    /// <summary>
    /// Clears all domain events (typically called after publishing)
    /// </summary>
    public void ClearDomainEvents() => _domainEvents.Clear();
}

/// <summary>
/// Base class for all entities in the domain
/// </summary>
public abstract class Entity<TId>
{
    public TId Id { get; protected set; } = default!;

    public override bool Equals(object? obj)
    {
        if (obj is not Entity<TId> entity || GetType() != entity.GetType())
            return false;

        return EqualityComparer<TId>.Default.Equals(Id, entity.Id);
    }

    public override int GetHashCode()
    {
        return EqualityComparer<TId>.Default.GetHashCode(Id);
    }
}

How Other Layers Interact with the Domain

One of the beautiful aspects of Clean Architecture is how the domain layer remains independent while other layers depend on it. Let's see how this works in practice:

Application Layer Usage

// Command handler in the Application layer
public class CreateAccountCommandHandler : IRequestHandler<CreateAccountCommand, Result<AccountDto>>
{
    private readonly IAccountRepository _accountRepository;
    private readonly ICurrentUser _currentUser;

    public async Task<Result<AccountDto>> Handle(CreateAccountCommand request, CancellationToken cancellationToken)
    {
        // Use domain factory method
        var account = Account.CreateNew(
            _currentUser.UserId,
            request.AccountType,
            new Currency(request.Currency));

        // Persist using repository abstraction
        await _accountRepository.AddAsync(account, cancellationToken);

        // Domain events will be published by infrastructure
        return Result<AccountDto>.Success(AccountDto.FromDomain(account));
    }
}

Infrastructure Layer Implementation

The key to maintaining clean separation of concerns is to automatically publish domain events when Entity Framework saves changes, rather than coupling this responsibility to repositories.

// Clean repository implementation - no event publishing concerns
public class AccountRepository : IAccountRepository
{
    private readonly AccountDbContext _context;

    public AccountRepository(AccountDbContext context)
    {
        _context = context;
    }

    public async Task<Account?> GetByIdAsync(Guid id, CancellationToken cancellationToken)
    {
        return await _context.Accounts
            .FirstOrDefaultAsync(a => a.Id == id, cancellationToken);
    }

    public async Task AddAsync(Account account, CancellationToken cancellationToken)
    {
        _context.Accounts.Add(account);
        // No event publishing here - it's handled automatically by EF interceptors
        await _context.SaveChangesAsync(cancellationToken);
    }

    public async Task UpdateAsync(Account account, CancellationToken cancellationToken)
    {
        _context.Accounts.Update(account);
        await _context.SaveChangesAsync(cancellationToken);
    }
}

Automatic Domain Event Publishing with EF Core Interceptors

To achieve true separation of concerns, we use Entity Framework interceptors to automatically publish domain events whenever changes are saved:

// Domain Event Publishing Interceptor
public class DomainEventPublishingInterceptor : SaveChangesInterceptor
{
    private readonly IDomainEventPublisher _eventPublisher;
    private readonly ILogger<DomainEventPublishingInterceptor> _logger;

    public DomainEventPublishingInterceptor(
        IDomainEventPublisher eventPublisher,
        ILogger<DomainEventPublishingInterceptor> logger)
    {
        _eventPublisher = eventPublisher;
        _logger = logger;
    }

    public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData,
        InterceptionResult<int> result,
        CancellationToken cancellationToken = default)
    {
        if (eventData.Context is not null)
        {
            await PublishDomainEventsAsync(eventData.Context, cancellationToken);
        }

        return await base.SavingChangesAsync(eventData, result, cancellationToken);
    }

    private async Task PublishDomainEventsAsync(DbContext context, CancellationToken cancellationToken)
    {
        // Find all aggregate roots with domain events
        var aggregateRoots = context.ChangeTracker.Entries<AggregateRoot<Guid>>()
            .Where(e => e.Entity.DomainEvents.Any())
            .Select(e => e.Entity)
            .ToList();

        // Collect all domain events
        var domainEvents = aggregateRoots
            .SelectMany(ar => ar.DomainEvents)
            .ToList();

        // Clear events from aggregates before publishing to prevent duplicate publishing
        foreach (var aggregateRoot in aggregateRoots)
        {
            aggregateRoot.ClearDomainEvents();
        }

        // Publish each domain event
        foreach (var domainEvent in domainEvents)
        {
            try
            {
                await _eventPublisher.PublishAsync(domainEvent, cancellationToken);
                _logger.LogInformation("Successfully published domain event {EventType} with ID {EventId}",
                    domainEvent.GetType().Name, domainEvent.Id);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Failed to publish domain event {EventType} with ID {EventId}",
                    domainEvent.GetType().Name, domainEvent.Id);

                // Re-add events to aggregate if publishing fails
                // This ensures events aren't lost if there's a publishing failure
                foreach (var aggregateRoot in aggregateRoots)
                {
                    aggregateRoot.AddDomainEvent(domainEvent);
                }

                throw; // Re-throw to prevent saving if event publishing fails
            }
        }
    }
}

DbContext Configuration

The DbContext configuration registers the interceptor to automatically handle event publishing:

public class AccountDbContext : DbContext
{
    public DbSet<Account> Accounts { get; set; } = null!;

    public AccountDbContext(DbContextOptions<AccountDbContext> options) : base(options) { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Configure Account entity
        modelBuilder.Entity<Account>(entity =>
        {
            entity.HasKey(a => a.Id);

            // Configure value objects
            entity.OwnsOne(a => a.AccountNumber, an =>
            {
                an.Property(x => x.Value)
                  .HasColumnName("AccountNumber")
                  .HasMaxLength(10)
                  .IsRequired();
            });

            entity.OwnsOne(a => a.Balance, money =>
            {
                money.Property(m => m.Amount)
                     .HasColumnName("Balance")
                     .HasPrecision(18, 2);

                money.OwnsOne(m => m.Currency, currency =>
                {
                    currency.Property(c => c.Code)
                           .HasColumnName("Currency")
                           .HasMaxLength(3);
                });
            });

            // Ignore domain events - they're not persisted
            entity.Ignore(a => a.DomainEvents);
        });
    }
}

Dependency Injection Setup

Finally, register everything in your DI container:

// In Program.cs or ServiceCollectionExtensions
public static IServiceCollection AddInfrastructure(
    this IServiceCollection services,
    IConfiguration configuration)
{
    // Register the domain event publisher
    services.AddScoped<IDomainEventPublisher, MassTransitDomainEventPublisher>();

    // Register the EF interceptor
    services.AddScoped<DomainEventPublishingInterceptor>();

    // Register DbContext with the interceptor
    services.AddDbContext<AccountDbContext>((serviceProvider, options) =>
    {
        var connectionString = configuration.GetConnectionString("DefaultConnection");
        var interceptor = serviceProvider.GetRequiredService<DomainEventPublishingInterceptor>();

        options.UseSqlServer(connectionString)
               .AddInterceptors(interceptor);
    });

    // Register repositories
    services.AddScoped<IAccountRepository, AccountRepository>();

    return services;
}

Benefits You'll Experience

By implementing rich domain models with automatic event publishing, you'll start noticing several significant benefits:

1. Business Logic Centralization

All rules related to accounts live in the Account entity. There's no scattered business logic across services, making the codebase more maintainable and easier to understand.

2. Improved Testability

You can unit test business logic without any infrastructure concerns. Domain entities can be tested in isolation, and the event publishing mechanism can be tested separately.

[Test]
public void Account_Deposit_Should_Raise_DepositProcessedEvent()
{
    // Arrange
    var account = Account.CreateNew(Guid.NewGuid(), AccountType.Checking, Currency.USD);
    account.Activate();

    // Act
    var result = account.Deposit(new Money(100, Currency.USD), "Test deposit", "REF123");

    // Assert
    Assert.That(result.IsSuccess, Is.True);
    Assert.That(account.DomainEvents.Count, Is.EqualTo(2)); // AccountCreated + DepositProcessed
    Assert.That(account.DomainEvents.OfType<DepositProcessedEvent>().Count(), Is.EqualTo(1));
}

3. Better Communication with Business Experts

Business experts can read and understand the domain code. The ubiquitous language is embedded directly in the code structure.

4. Automatic Consistency Guarantees

• Invariants are always maintained within aggregates
• Domain events are published automatically after successful persistence
• No risk of forgetting to publish events or publishing them incorrectly

5. True Event-Driven Capabilities

The EF interceptor approach enables:

• Automatic event publishing: No manual intervention required
• Transactional consistency: Events are only published if database changes succeed
• Clean separation: Repository logic remains focused on data persistence
• Loose coupling: Domain events enable eventual consistency across bounded contexts

6. Resilient Event Publishing

The interceptor pattern provides built-in resilience:

• Events are cleared before publishing to prevent duplicates
• Failed event publishing prevents database commits
• Events are re-added to aggregates if publishing fails, ensuring no loss

Common Pitfalls to Avoid

As you start implementing rich domain models, watch out for these common mistakes:

1. Overly Large Aggregates: Keep aggregates focused and small. If an aggregate is doing too much, consider splitting it
2. Missing Business Rules: Don't let business logic leak into application services
3. Anemic Events: Domain events should be meaningful business events, not just "data changed" notifications
4. Ignoring Ubiquitous Language: Use the same terms that business experts use

Conclusion

Rich domain models are the heart of any successful Domain-Driven Design implementation. By encapsulating business logic within entities and value objects, we create code that not only works but also communicates intent clearly and maintainably.

The Account aggregate we've built demonstrates how to:

• Protect business invariants through careful encapsulation
• Express business operations as meaningful methods
• Use value objects to create type-safe, expressive APIs
• Leverage domain events for loose coupling and event-driven architecture

In our next article, we'll explore how to publish these domain events using MassTransit and Azure Service Bus, enabling true event-driven microservices architecture. We'll see how the events generated by our rich domain models can trigger workflows across different bounded contexts, maintaining consistency while keeping services loosely coupled.

Remember, DDD isn't just about patterns—it's about creating software that reflects and supports the business domain it serves. Rich domain models are your first step toward achieving that goal.

---

Next in the series: "Publishing Domain Events with MassTransit and Azure Service Bus" - Learn how to build event-driven microservices that react to domain changes.

---

📋 Resources

• Example Code Repository
• Domain-Driven Design by Eric Evans
• Clean Architecture by Robert C. Martin
• .NET Application Architecture Guides