Tag Persistence Model

Having the domain model separated from the persistence model

In this post, I’d like to write about a pretty common discussion in DDD circles: should one have the domain model separated from the persistence model? In other words, should you map your domain objects to the DB tables directly using an ORM or would it be better to use a separate set of Data Access Objects (DAOs) instead?
Vladimir Khorikov
Vladimir Khorikov
Twitter Email LinkedIn
My book
Unit testing book
Click here to get a 40% discount
Pluralsight courses
Pluralsight ‒ Pragmatic Unit Testing
‒ Domain-Driven Design in Practice
‒ Applying Functional Principles in C#
‒ Database Delivery Best Practices
‒ Specification Pattern in C#
‒ Refactoring from Anemic Domain Model
‒ Domain-Driven Design: Working with Legacy Projects
‒ CQRS in Practice
‒ DDD and EF Core: Preserving Encapsulation
‒ Validation and DDD
‒ Encapsulating EF Core Usage
‒ Prepare for coding interviews with CodeStandard
citadel Citadel Password Manager Privacy first. No data collected, period.
Most Popular Articles
‒ EF Core 2.1 vs NHibernate 5.1: DDD perspective
‒ C# and F# approaches to illegal states
‒ Optimistic locking and automatic retry
‒ Entity vs Value Object: the ultimate list of differences
‒ DTO vs Value Object vs POCO
‒ 3 misuses of ?. operator in C# 6
‒ Specification pattern: C# implementation
‒ Database versioning best practices
‒ Unit testing private methods
‒ Functional C#: Handling failures, input errors
‒ REST API response codes: 400 vs 500
MSMVP
Recent Articles
‒ Storing information in its highest form
‒ Which collection interface to use?
‒ Generic types are for arguments, specific types are for return values
‒ Modeling Relationships in a DDD Way
‒ Encapsulating EF Core Usage: New Pluralsight course
‒ Collections and Primitive Obsession
‒ How to Assert Database State?
‒ Should you Abstract the Database?
‒ Database and Always-Valid Domain Model
‒ Specification Pattern vs Always-Valid Domain Model
» All articles