Domain-Driven Design tactical patterns for .NET applications. Covers aggregates, aggregate roots, value objects, domain events, domain services, strongly-typed IDs, and repository patterns for aggregate persistence. Load this skill when implementing DDD, working with aggregates, value objects, domai

Domain Driven Design (DDD) Core Principles 1. Aggregates define consistency boundaries — An aggregate is a cluster of entities and value objects treated as a single unit for data changes. All invariants within an aggregate are enforced in a single transaction. Cross aggregate consistency is eventual. 2. Value objects over primitives — Replace primitive obsession with value objects. Money , EmailAddress , OrderNumber are not strings — they carry validation, equality, and behavior. Use C records for immutable value objects. 3. Domain events decouple side effects — When something meaningful happens in the domain (OrderPlaced, PaymentReceived), raise a domain event. Side effects (send email, update read model, notify another aggregate) subscribe to these events. The aggregate stays focused on its own rules. 4. Aggregate root is the sole entry point — External code accesses an aggregate only through its root entity. Child entities are never loaded or modified independently. The root enforces all invariants for the entire aggregate. 5. Repositories persist aggregates, not entities — One repository per aggregate root. The repository loads and saves the entire aggregate as a unit. No repository for child entities. The Infrastructure implementation uses DbContext internally — this is a DDD tactical pattern for aggregate boundaries, not a generic CRUD wrapper. Patterns Aggregate Root The aggregate root owns all access to its children and enforces invariants: Value Objects as Records Use C records for immutable value objects with structural equality: Strongly Typed IDs with EF Core Converters Prevent mixing up GUIDs from different entities: Domain Event Dispatching Raise events in the aggregate, dispatch in SaveChangesAsync: Domain Services For logic that does not belong to a single aggregate: Anti patterns Oversized Aggregates Domain Events for Intra Aggregate Logic Value Objects with Identity Anemic Aggregates Decision Guide Scenario Recommendation When to use DDD Complex domain with business rules that go beyond CRUD When to use value objects Any concept with validation rules or equality based on attributes, not identity Aggregate size Keep small — typically 1 root entity + 0 3 child entities. Load the whole aggregate every time Domain events vs integration events Domain events: within bounded context, same transaction. Integration events: cross context, via message bus Strongly typed IDs Always for aggregate root IDs that cross boundaries. Optional for child entity IDs When NOT to use DDD Simple CRUD, settings, audit logs, read models — use plain entities Repository vs DbContext Repository per aggregate root for complex aggregates; IAppDbContext for simpler queries Domain services Only when logic requires multiple aggregates or external data the aggregate should not know about

ddd