domain driven design - Is this how to structure classes for DDD? -

assume have relationship every customer has address (which in case, entity), below:

customer{ id, name, myaddress (instance of address) }

should allowing structure exposes following option:

mycustomer.myaddress.street = "pine street"; customerrepository.save(mycustomer); 

should cascade save, both customer class , address class? or, better perform following:

mycustomer.myaddress.street = "pine street"; addressrepository.save(mycustomer.myaddress); 

unfortunately, address value object, cannot make interchangable ddd requires id tag present; example, if did following:

customer1.setaddress(customer2.getaddress()); 

both customer1 , customer2 have same binding same record, dangerous.

none of samples ddd. each 1 simple crud.

1. don't "set fields". meaningful operations.

customer.moveto(new address(...)) customer.fixaddresstypo(new address(...)) 

1. repositories aggregates, not entities. identify aggregates. http://dddcommunity.org/library/vernon_2011/

2. why not map addres value object bunch of fields in cutomers table? don't need separate table because have separate class.

3. value objects should immutable.