Thoughts

• Once you start relying on aggregates being loaded as 'entity sets', they must be loaded as such. While this is possible with EF, it is error-prone if you need to load the same aggregate in multiple places. To get around this you need to use a repository to load the aggregate root and all of its related entities in a single query.
• Initially, I thought we could use repositories for commands, and then use the DbContext directly for queries, but if your queries rely on any computed properties that rely on the whole aggregate this isn't possible. Could get around this though, by not using computed properties and instead storing the computed value in the DB.
• Can't pass owned entities to constructors, so will need to use factory methods for those.
• Business logic and validation can now be easily unit tested in isolation via AggregateRoot tests.
• DDD + CQRS is a heavy-weight solution. It gives us great control by ensuring entities are always in a valid state, but there is additional complexity across both the Domain and Application that are required to support this. Perhaps only ideal for 'Large' projects.
• If you have a massive Aggregate root, but just need to update a simple property on one of the entities, you will need to load the whole aggregate root. This could be a performance issue.
• Some interfaces need to be pushed to the domain layer
• IMHO the repository interface remains in the application, NOT the domain as this is a persistence concern. The domain should not be concerned with persistence.
• IMHO we should not have separate domain entities and data models. We can keep the domain entities as they are, but we can use EF to configure the persistence. This saves on a lot of double handling.