Domain model is the peristence model. Splitting them apart is often known as an anemic domain model (in Domain Driven Design). All the domain logic is on the e

Domain model is the peristence model. Splitting them apart is often known as an anemic domain model (in Domain Driven Design). All the domain logic is on the entity. So our command handlers (akin to your service methods) look like: 1. Load entity 2. Call method on entity, passing in data 3. Save entity 4. Raise events So we only unit test 2. because that's the domain code. Loading entities from the dbContext is someone else's code. So is saving. So is raising events. If your entity class gets big, split out the functionality into other classes so that you end up with a fair portion of bodyless methods. Hope this is making sense!