linq to sql - Applying Domain Model on top of Linq2Sql entities -

i trying practice model first approach , putting domain model. requirement pretty simple: usersession can have multiple shoppingcartitems.

i should start off saying going apply domain model interfaces linq2sql generated entities (using partial classes). requirement translates 3 database tables (usersession, product, shoppingcartitem productid , usersessionid foreign keys in shoppingcartitem table). linq2sql generates these entities me. know shouldn't dealing database @ point think important mention.

the aggregate root usersession shoppingcartitem can not exist without usersession unclear on rest. product? defiently entity should associated shoppingcartitem?

here few suggestion (they might incorrect implementations):

public interface iusersession {     public guid id { get; set; }     public ilist<ishoppingcartitem> shoppingcartitems{ get; set; } }  public interface ishoppingcartitem {     public guid usersessionid { get; set; }     public int productid { get; set; }         } 

another 1 be:

public interface iusersession {     public guid id { get; set; }     public ilist<ishoppingcartitem> shoppingcartitems{ get; set; } }  public interface ishoppingcartitem {     public guid usersessionid { get; set; }     public iproduct product { get; set; }          } 

a third 1 is:

public interface iusersession {     public guid id { get; set; }     public ilist<ishoppingcartitemcolletion> shoppingcartitems{ get; set; } }  public interface ishoppingcartitemcolletion {     public iusersession usersession { get; set; }     public iproduct product { get; set; }       }  public interface iproduct {     public int productid { get; set; }       } 

i have feeling mind tightly coupled database models , tables making hard grasp. care decouple?

looks on right track. half of whole "doing ddd right" having right base classes. have @ great ddd applied c# resource:

http://dddpds.codeplex.com/

the source code available , readable.

so, regards having id in model. id database thing , usual approach keep persistence out of model , restrict model business logic. however, 1 makes exception identifier , buries in model base class so:

public class modelbase {   protected readonly object m_key;   public modelbase(object key) {     m_key = key;   } } 

this key used persistence layer talk database , opaque. it's considered quite ok downcast key required type, because know is.

also, domain objects pretty on bottom of architecture stack (just above infrastructure layer). means can make them concrete classes. not have multiple implementations of domain models, interfaces unnecessary, domain driven design - domain first.

public class usersession : modelbase {   public usersession(guid id):base(id) {}    public guid id { get{ return m_key guid;} }   public ilist<shoppingcartitem> shoppingcartitems{ get; set; } }  public class shoppingcartitem : modelbase {   public shoppingcartitem ():base(null) {}    public usersession usersession { get; set; }   public product product { get; set; }          }