Your domain classes should be focused on business logic of domain only, and they should be persistent ignorant (i.e. persistence should be separated from business logic). Adding persistence-related operations violates Single Responsibility Principle. Also dependency on repository makes your domain classes complex, instead of being simple POCO entities.
Let's think about this design from coding point. You have to provide repository instance to each Order
, and then call order.Insert()
for this order to pass itself to repository which you have injected into order. Sounds complicated. Much simpler will be use repository.Save(order)
. Sometimes it's OK to have CRUD methods on class (see Active Record pattern). But this approach is good when you don't have complex domain model.
I think best place for persistence of your domain is application services (maybe you call this layer as Service layer). They load entities from repositories, perform operations (it could be simple operations on entities, or calls to domain services), and then state of domain gets saved.