Clean Architecture & DDD Mastery

Handling Persistence Ignorance with EF Core

1 Views Updated 5/4/2026

Persistence Ignorance

Persistence Ignorance is the principle that your domain objects should not know how they are saved to a database.

1. The EF Core Conflict

EF Core usually wants public setters and parameterless constructors. DDD wants private setters and rich constructors. To solve this, we use **Entity Configurations** in the Infrastructure layer. We use .HasField() and .UsePropertyAccessMode() to tell EF Core to use our private backing fields instead of our public properties.

2. Shadow Properties

Sometimes you need data for the database (like a Version column for concurrency) that the domain doesn't care about. You can define these as **Shadow Properties** in EF Core. They exist in the database and the DbContext, but they never appear in your C# Domain Entity. This keeps your domain pure.

3. Architect Insight

Q: "Should I use Data Annotations like [Key] in my Domain?"

Architect Answer: "NO. That is a violation of Clean Architecture because your Domain now depends on System.ComponentModel.DataAnnotations, which is a persistence detail. Always use the **Fluent API** in the Infrastructure layer's OnModelCreating to define your database schema. The Domain stays 100% POCO (Plain Old CLR Object)."

Clean Architecture & DDD Mastery
1. Architectural Patterns
The Evolution of Architecture: Monolith to Clean Onion Architecture: Dependency Inversion at the core Clean Architecture: The 'Screaming' architecture Hexagonal Architecture (Ports and Adapters)
2. Domain-Driven Design (DDD) Foundations
Ubiquitous Language: Aligning code with business Entities vs Value Objects: Managing identity and state Aggregates & Aggregate Roots: Defining consistency boundaries Bounded Contexts: Handling complexity in large domains
3. Advanced DDD Patterns
Domain Services: When logic doesn't fit in an entity Domain Events: Decoupling side effects via events Repositories: Mediating between domain and data Unit of Work: Ensuring atomic transactions
4. Implementing the Clean Layers
The Domain Layer: Zero dependencies, pure C# The Application Layer: Orchestrating use cases The Infrastructure Layer: Bridging to the outside world The Presentation Layer: Decoupling the UI from logic
5. Patterns for Data & Logic
CQRS (Command Query Responsibility Segregation) MediatR: Implementing the Mediator pattern in .NET Specification Pattern: Encapsulating business rules Policy Pattern: Handling complex authorization rules
6. Enterprise Domain Challenges
Handling Persistence Ignorance with EF Core Mapping Layers: AutoMapper vs Manual Mapping Validation Strategies: FluentValidation in the App Layer Error Handling: Result patterns vs Exceptions
7. Testing Clean Architecture
Unit Testing the Domain: Fast and pure Testing Use Cases with Mocks Integration Testing the Infrastructure ArchUnit .NET: Enforcing architectural rules via tests
8. Real-World Case Study
Refactoring a 'Spaghetti' Monolith to Clean Architecture DDD in Action: Modeling a complex Logistics system