domain driven design - How do I handle persistence and unit of work in DDD using Entity Framework? -

i'm little overwhelmed of information on ddd, unit of work, domain services, app services, etc. i'm trying figure out how persistence-ignorant domain model gets persisted, in context of unit-of-work , entity framework. let's have order aggregate root, attempting keep in persistence-ignorant domain model (the core of architectural onion):

public class order : entitybase {     public int id { get; private set; }     public int marketplaceid { get; private set; }     public int customerid {get; set;}     public list<orderitem> items { get; private set; }     public list<ordercomment> comments { get; private set; }      public void additem(orderitem item) { /**add item**/ }     public void addcomment(ordercomment comment) { /**add comment**/ }     public override bool validate() { /**validate**/ }     public void cancel() { /**cancel**/ } } 

let's have process updates property on order entity, example changes customerid associated order.

i have iorderrepository in domain layer, have implementation (in outer layer) function this:

order getorder(int orderid) {     //get entity framework order, items, etc.     //map domain-layer order , return domain-layer order }  void updateorder(order order) {     //get entity framework order, order items, order comments, etc.     //take domain order (passed in function), , update ef items fetched above     //use single ef unit of work commit these changes } 

there's wrong approach. updateorder function seems heavy small change; seems have if repository isn't aware of items on persistence-ignorant domain model have changed. should handling every type of update in separate repository function? updatemarketplace(int marketplaceid), updatecustomer(int customerid)?

as i'm typing this, i'm wondering...maybe way have above not heavy? if change 1 property, though i'm doing of above, perhaps entity framework recognize values being assigned same , send 1 db column update sql?

how can take order domain model (fetching straightforward enough), perform operation or operations on may limited in scope, , persist model using entity framework?

you need unit of work pattern. uow keeps track of changes, when order repository , modify it, call unitofwork.savechanges() should persist changes.

using entity framework, dbcontext unit of work create simpler interface around can abstract away easier usage in higher layers.

regarding ef, recommend mapping domain entities directly using code first approach. turn off lazy loading , magic stuff have full control , less "surprises".

unfortunately i'm not allowed share our code have working pretty new ef6 alpha 3. recommend taking @ microsoft spain's nlayerapp implementation examples. don't agree many of design decisions (also, see review), think can draw inspiration entity framework parts. take @ unit of work implementation , how have abstracted away easier usage in higher layers, , how use in application services.

i recommend looking creating generic repository avoid duplicating lots of logic in aggregate specific repositories. ms spain has 1 here, should take @ thread.