dotnet-tactical-ddd

# .NET Tactical Domain-Driven Design

## Overview

**Rich domain models with behavior, not anemic data containers.** Apply tactical DDD patterns to all .NET backend development for maintainable, testable, domain-centric code.

**Core principle:** Domain models encapsulate business rules and invariants. DTOs are immutable data contracts at API boundaries. Manual mapping via extension methods. Never expose domain models in APIs.

**Base classes:** See [base-classes.cs](base-classes.cs) for `Result<T>`, `ValueObject`, `AggregateRoot<T>`, `IDomainEvent` implementations. Copy into your `Domain/` project.

## 0. The Dependency Rule (Foundation)

**Dependencies point inward only.** Outer layers depend on inner layers, never the reverse.

```
Infrastructure → Application → Domain
   (adapters)     (use cases)    (core)
```

**Violations to catch:**
- Domain/ importing `Microsoft.EntityFrameworkCore`, `System.Net.Http`, `Serilog`
- Controllers calling repositories directly (bypassing Application/ use cases)
- Entities depending on application services
- Application/ directly instantiating Infrastructure/ classes (should use DI)

**Verification test:** "Can I run domain logic from unit tests with no database/HTTP/file system?" If yes, boundaries are correct.

## Layer Decision Tree

**Where does this code go?**

| Code Type | Layer | Example |
|-----------|-------|---------|
| Pure business logic, no I/O | `Domain/Entities/` or `Domain/ValueObjects/` | `OrderLine.CalculateTotal()` |
| Business rule across entities | `Domain/Services/` | `IPricingService.CalculateDiscount()` |
| Orchestrates domain + calls infra | `Application/{UseCase}/Handler` | `CreateOrderHandler` |
| Interface for external dependency | `Domain/Interfaces/` (if domain needs it)<br>`Application/Common/Interfaces/` (if only app uses) | `IEmailService` interface |
| Database implementation | `Infrastructure/Persistence/` | `OrderRepository` |
| HTTP/external API call | `I