Domain-Driven Design in ASP.NET Core: Tactical Patterns and Enterprise Adoption Decision Guide
Enterprise .NET teams face a recurring architectural fork in the road: should this service be built with rich domain models and DDD tactical patterns, or is a simpler CRUD approach good enough? Make the wrong call and you are either carrying unnecessary complexity in a simple CRUD system, or you are fighting an anemic domain model in a system that desperately needed real business logic encapsulation.
This guide gives you the decision framework, the pattern vocabulary, and the trade-off map to make that call confidently in ASP.NET Core.
🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 Join us on Patreon
When DDD Earns Its Keep
Domain-Driven Design is an investment. The return only materialises when the domain is genuinely complex—when the rules, relationships, and invariants of the business are not trivially mapped to database rows.
Apply DDD when you have:
Rich, interconnected business rules that span multiple entities and must be enforced consistently
Rapidly evolving domains where requirements change frequently and business experts are heavily involved
Long-lived systems where the cost of refactoring an anemic model compounds over years
Distributed or microservice architectures where bounded contexts naturally map to service boundaries
Skip DDD (or defer it) when you have:
Simple CRUD screens with minimal invariants
Short-lived projects or proofs of concept
Teams unfamiliar with the patterns who will introduce them inconsistently
Data-centric reporting workloads where there is no meaningful behaviour to encapsulate
The honest signal for enterprise teams: if your architects spend more time arguing about whether an entity should be an Aggregate Root than building features, DDD is being misapplied or over-engineered for the context.
Bounded Contexts: The Strategic Prerequisite
Before any tactical pattern is applied, the bounded context must be drawn. A bounded context is the boundary within which a particular domain model is valid and consistent. Outside that boundary, a different model—possibly with the same vocabulary but different semantics—applies.
In an e-commerce system, "Customer" in the Sales context carries loyalty tier, order history, and payment preferences. In the Shipping context, "Customer" is a delivery address and contact name. These are different models, and conflating them into a single entity is the root cause of many enterprise monolith maintenance nightmares.
ASP.NET Core physical structure should reinforce bounded context boundaries. Each context typically lives in its own project or assembly, with its own domain layer, application layer, and infrastructure layer. Shared nothing is the goal; shared kernel (a deliberate, minimal, agreed-upon subset) is the pragmatic middle ground.
The bounded context boundary is also where team ownership should sit. Conway's Law is real. If two teams share a model, they will fight over it. Draw the context boundary to match the organisational boundary and the maintenance story improves dramatically.
Entities and Identity
Entities are objects that are defined by their identity, not their attributes. Two entities with the same property values are not the same entity if they have different identifiers. This is the fundamental distinction between entity semantics and value object semantics.
In ASP.NET Core enterprise systems, entities should:
Encapsulate state changes behind methods, not expose public setters
Enforce invariants at the point of mutation, not in application-layer validation that can be bypassed
Hold no knowledge of persistence, the HTTP layer, or infrastructure concerns
The common antipattern is an entity that is nothing more than a property bag—every field is a public get/set, all validation lives in a service layer, and the entity itself carries no behaviour. This is the anemic domain model, and it is not DDD. It is a data class wearing domain clothing.
Value Objects: Immutability as a Feature
Value objects are defined by their attributes, carry no identity, and are inherently immutable. Two value objects with the same attribute values are equal. They represent concepts that should travel together and be validated together.
An Address is a value object—street, city, postal code, and country have no meaning in isolation, and an address with the same fields is interchangeable with another address with the same fields. A Money type pairing amount and currency is a value object—it prevents the class of bugs that arise from treating raw decimals as money.
In C# and ASP.NET Core, value objects map naturally to record types (immutable by default with structural equality) or to classes implementing IEquatable<T> with protected equality comparers. Records eliminate most of the boilerplate that historically made value objects tedious to implement.
The enterprise benefit of value objects extends beyond correctness. When concepts like Money, EmailAddress, PhoneNumber, or TaxRate are modelled as types, the compiler becomes a collaborator in enforcing correctness. Passing a raw decimal where a Money is expected is a compile-time error, not a runtime surprise in production.
Aggregates: Consistency Boundaries in Practice
The Aggregate is the most misunderstood DDD tactical pattern. An aggregate is a cluster of domain objects treated as a single unit for the purpose of data changes. Every aggregate has one entity designated as the Aggregate Root. All external interaction happens through the root. No external object holds a direct reference to a non-root entity inside the aggregate.
The aggregate boundary defines the consistency boundary. Everything inside a single aggregate is guaranteed to be consistent after any operation. Consistency across aggregates is eventual, coordinated through domain events or sagas.
Sizing aggregates correctly is a genuine skill. Too large an aggregate and you have a god object with lock contention issues at scale. Too small and you lose the consistency guarantees that motivated the pattern in the first place.
Practical enterprise guidance for aggregate sizing:
Start small. A single entity is often a valid aggregate boundary. Grow it only when invariants force you.
Identify invariants that must be consistent together. If two entities have a rule that must hold atomically, they likely belong in the same aggregate.
Every aggregate write should fit in a single database transaction. If you find yourself needing cross-aggregate transactions, your boundary is wrong.
Reference other aggregates by identity only. An
Orderaggregate containsOrderItementities but holds only theCustomerId(an identity reference), not the fullCustomeraggregate.
In an ASP.NET Core system, aggregate roots are typically loaded from a repository, mutated via methods on the root, and saved back. The root is responsible for validating that mutations preserve all invariants.
Domain Events: Decoupling Without Losing Semantics
Domain events are records of something that happened within the domain. They are named in the past tense—OrderPlaced, PaymentDeclined, CustomerRegistered—because they represent facts, not intentions.
Domain events serve two purposes in enterprise ASP.NET Core systems:
Intra-aggregate side effects: When an operation on an aggregate should trigger behaviour elsewhere in the same bounded context, a domain event raised by the aggregate root and handled synchronously within the same transaction preserves consistency without creating tight coupling between domain objects.
Inter-context integration: When an event must cross a bounded context boundary—an OrderPlaced event in the Sales context triggering inventory reservation in the Warehouse context—the event becomes an integration event, published asynchronously via a message broker and delivered reliably using the Outbox pattern.
The distinction matters. Intra-aggregate domain events are in-process, synchronous, and part of the same transaction. Integration events are out-of-process, asynchronous, and handled eventually. Conflating the two is a design error that leads to either tight coupling or data consistency bugs.
In ASP.NET Core, the typical approach raises domain events on the aggregate root as a list, collected during the operation, and dispatched by the infrastructure layer after the aggregate is persisted. MediatR or a lightweight in-process event bus handles the dispatch.
Repositories: Persistence Abstraction for the Domain
The Repository pattern gives the domain layer the illusion that aggregates live in an in-memory collection. The application layer asks the repository for an aggregate by identity, receives a fully reconstituted domain object, operates on it, and returns it to the repository. All persistence details—SQL, EF Core, document storage—live behind the repository interface, invisible to the domain.
Enterprise trade-offs to understand before adopting repositories:
Repository vs. direct EF Core DbContext: A repository wrapping EF Core adds indirection. If your team is disciplined about keeping queries out of domain logic, using the DbContext directly from the application layer with CQRS—specifically, bypassing the repository for reads and going directly to the data layer—can reduce ceremony without sacrificing the write-side consistency benefits.
Generic vs. typed repositories: A generic IRepository<T> provides code reuse but leaks persistence concerns into the interface (pagination parameters, expression trees). Typed repositories like IOrderRepository with semantically meaningful methods (FindByCustomerId, FindOverdueOrders) are more expressive and testable, at the cost of more interfaces to maintain.
Unit of Work coordination: In EF Core, the DbContext is already a unit of work. Adding a separate UoW abstraction over it creates double abstraction with minimal benefit unless you need to coordinate multiple data sources within a single transaction.
Aggregates and EF Core: Practical Mapping
EF Core owned entity types map naturally to value objects. An Address value object owned by a Customer entity maps to owned type configuration, storing the address columns inline on the customer table without requiring a separate entity identity.
Aggregate boundaries align with DbContext configuration scoping. The entities within an aggregate should be configured as owned types or private navigation properties unreachable via direct DbSet queries. External code cannot accidentally bypass the aggregate root by querying child entities directly.
For teams adopting DDD incrementally, starting with explicit DDD patterns on the write side while using lightweight projections or Dapper for the read side (CQRS at the infrastructure level) delivers the domain model benefits without requiring every read path to traverse aggregate boundaries.
💻 Want to see these patterns in a runnable project? Check out our ASP.NET Core code samples on GitHub — including Global Exception Handling, Request Correlation Middleware, and Minimal API Endpoint Filters. Clone them, run them, and adapt them to your own architecture.
The Adoption Decision Matrix
No pattern should be adopted wholesale across a system. Apply DDD tactically by domain complexity:
High complexity, core domain: Full DDD—bounded contexts, rich aggregates, value objects, domain events, repositories with Unit of Work. The investment is justified by the complexity and strategic importance.
Medium complexity, supporting domain: Selective application—use value objects for type safety and aggregate boundaries for critical invariants, but skip event-based side-effect handling if it adds more complexity than it removes.
Low complexity, generic subdomain: CRUD with minimal ceremony. A generic CRUD service with EF Core and validation in the application layer is appropriate. Do not apply DDD patterns to invoice generation utilities or audit log writers.
The maturity signal for enterprise teams: if domain experts and developers share the same vocabulary and can review code together without translation, DDD is delivering on its core promise. If the patterns are adding ceremony without improving communication, they are being misapplied.
Common Anti-Patterns to Eliminate
Anemic domain model: Entities with only properties and no behaviour, with all logic in service classes. This is procedural programming in OOP clothing. Behaviour belongs on the entity that owns the data.
Fat application service: An application service that has grown to contain all business logic because entities were kept thin. The service becomes untestable without full infrastructure setup and impossible to maintain.
Leaky aggregate: External code holds references to entities inside an aggregate and modifies them directly, bypassing the root and invalidating invariants. Enforce the boundary through access modifiers and EF Core navigation property configuration.
Over-eager domain events: Raising domain events for every property change rather than for meaningful business facts. This floods the event bus with noise and makes event consumers brittle.
Cross-aggregate transactions: Using a single database transaction to ensure consistency across two aggregates. If this is necessary, the aggregate boundaries are wrong. Redesign using eventual consistency with domain events and compensation.
☕ Found this article helpful? Buy us a coffee — it helps us keep producing free, high-quality .NET content every week.
FAQ
Is DDD only for microservices?
No. DDD originated in the context of large monoliths and the patterns apply equally to monolithic ASP.NET Core applications. The bounded context is a logical boundary that can exist within a single deployable unit. Microservices are one way to enforce that boundary with a physical deployment boundary, but they are not required. Many teams successfully apply DDD inside a modular monolith and extract services later when operational justification exists.
How do I know if my aggregate is sized correctly?
A practical test: can a single aggregate operation complete in a single database transaction without loading other aggregates? If yes, the size is likely appropriate. If your application service routinely loads multiple aggregates in a single operation to enforce a single rule, those aggregates may need to be merged, or the rule may be better enforced eventually through domain events. Lock contention and transaction timeouts under load are also symptoms of over-sized aggregates.
What is the difference between a domain event and an integration event?
A domain event is an in-process notification that something happened within a bounded context. It is dispatched synchronously, handled within the same transaction, and used to coordinate side effects within the same context. An integration event crosses bounded context boundaries, is published to a message broker, and is handled asynchronously. The Outbox pattern ensures integration events are published reliably even if the broker is temporarily unavailable.
Should every entity be an aggregate root?
No. Aggregate roots are entities that own a consistency boundary. Many entities within a domain model are child entities that belong inside an aggregate and have no meaningful existence outside it. An OrderItem has no meaningful existence outside an Order. It should be an entity within the Order aggregate, accessible only through the Order root. Creating a repository for every entity is a common DDD anti-pattern that eliminates the consistency guarantees that aggregates provide.
Can I mix DDD aggregates with CQRS?
Yes, and this combination is common and recommended in enterprise ASP.NET Core systems. CQRS separates the write model (commands that mutate aggregates) from the read model (queries that project data for display). DDD aggregates are ideal for the write side—they enforce invariants and raise domain events. The read side bypasses aggregates entirely, going directly to the database with optimised queries (EF Core with AsNoTracking, Dapper, or raw SQL) to project read-optimised DTOs. This avoids loading aggregate complexity just to render a list view.
How does DDD interact with EF Core change tracking?
EF Core change tracking works at the DbContext level and tracks all loaded entities. When aggregate roots are loaded, their child entities are tracked as well. The aggregate root controls the lifecycle—you should not add child entities directly to a DbSet outside the aggregate root methods. Configure EF Core to use private navigation properties and access modifiers that prevent external code from bypassing the aggregate boundary. The HasMany or WithMany configuration with UsePropertyAccessMode set to Field is the standard approach for enforcing boundary integrity through EF Core configuration.
