domain driven design - Building models in NOSQL -

we trying nosql document database (ravendb) , asking ourselves questions. our models :

public class user {        public guid id {get;set}     public string name {get;set;}    }  public class video {     public guid id {get;set;}     public string nom {get;set;}         public datetime publishdate {get;set;}     public user publisher {get;set;}     public uri adress {get;set;} } 

by default, video can not read anyone. can add rights see video @ user or group of user. can recommand video user or group of user(the rights see video added automatically).

what best way design models nosql document database considering following use case :

• a user publishing video can choose group(s)/user(s) can see video , recommend video user(s)/group(s)
• a user withdraw rights see video @ user(s)/group(s)
• get last n videos user has been authorized read
• get last n videos have been recommended user

we considering following :

• add 2 list each model (videosreadable, videosrecommended , usersallowedtoread, userrecommended) first list contains elements of second
• add list of tuple each model (listtuple<user, bool>> , list<tuple<video, bool>>), bool indicates if recommended.
• add document uservideolink

which 1 easiest model querying ? there other better alternatives?

it comes down quantities. how many potential users total? how many potential videos total? how many recommendations , assignments? how data change? there no 1 best answer.

you may find, example, if have lot of better off creating separate documents model active bits, such separate class , document model recommendation , model assignment.

then again, if 1 user has access handful of videos, may find easier embed list of videoids in each user, or list of video objects may or may not full video document or a small denormalized piece of data.

you'll have experiment , decide works best you.

however, i'd stay away using tuple. bit messy. you'd better class of own creation purpose.

i avoid name uservideolink - doesn't fit ddd ideas well. think of more modeling instead, such recommendation.

some of may sound relational-database thinking, have place in document databases also. because document can have structure doesn't mean has go in single document. try model domain first using ddd concepts. you've identified "aggregate root" entity, , child entities thereof, (usually) belong in single document.