CODEWITHSUNDEEP
domain-driven-designrepository-pattern
AdrianGW
AdrianGW

Reputation: 153

Is this how to structure classes for DDD?

Assume I have the relationship where every customer has an address (which in this case, is an entity), like below:

Customer{ Id, Name, MyAddress (instance of Address) }

Should I be allowing a structure that exposes the following option:

MyCustomer.MyAddress.Street = "Pine Street";
CustomerRepository.Save(MyCustomer);

Should this cascade a save, both for the Customer class and for the Address class? Or, is it better to perform the following:

MyCustomer.MyAddress.Street = "Pine Street";
AddressRepository.Save(MyCustomer.MyAddress);

Unfortunately, Address really is a value object, but I cannot make it interchangable like DDD requires as the Id tag is present; for example, if I did the following:

Customer1.setAddress(Customer2.getAddress());

Both Customer1 and Customer2 now have the same binding to the same record, which is dangerous.

Upvotes: 0

Views: 595

Answers (1)

Bartłomiej Szypelow
Bartłomiej Szypelow

Reputation: 2121

None of your samples is DDD. Each one is simple CRUD.

  1. Don't "set fields". Do meaningful operations.
customer.MoveTo(new Address(...))
customer.FixAddressTypo(new Address(...))

  1. Repositories are for aggregates, not any entities. Identify your aggregates. http://dddcommunity.org/library/vernon_2011/

  2. Why not map the Addres value Object as a bunch of fields in the Cutomers table? You don't need separate table just because you have a separate class.

  3. Value objects should be immutable.

Upvotes: 2

Related Questions