Comments by fastal (Top 3 by date)

I think you are on a track that would work.

I would think if you are still going to use repositories, do the mapping between the EF objects and YOUR objects INSIDE the repositories. Here is a great post that goes into more detail about doing it that way:
https://stackoverflow.com/questions/24588838/entities-vs-domain-models-vs-view-models

I refer to the same things when I say 'domain objects' and 'business objects' - but not all writers do that, I see. In that post, it appears as though they may mean the EF objects by 'domain' objects - although I'm not sure, that seems a non-standard way of doing it. Sorry for using both of the terms.

You will see most people don't talk about the 'DDD-Services' layer for composing and integrating your business objects. This example is no exception. Just make room for it in your project - it is not a layer that all properties need to be mapped to nor 'thru' - when you have some complicated inter-object logic, though, it may make more sense to make a new object in the services layer, inject the business objects that need the work done, and do the work there, to avoid mixing references to objects. Note - this is about 10% of the logic that really needs it, but, usually it's the more complicated logic ;-)

If your business objects don't hold references to repositories, it makes unit tests easier, there is less to mock... I would not recommend mocking nor abstracting your business objects either to test your domain layer objects - this will result in less granular units as they depend on the business objects, but if your business objects have good tests, that will mitigate this. This will give you most of the value of the tests without the technical debt of abstracting your business objects (which takes more than it gives). If this last paragraph doesn't make sense, ignore it ;-)