Confused on some DDD concepts

1
votes

I have some questions regarding some DDD concepts:

  1. In Evans' book about DDD, in section VALUE OBJECTS, he says to put attributes that make up a conceptual whole in VALUE OBJECTS like in his Address objects example. I can't seem to see the benefits of this than just leaving the attributes inside the Customer entity. What would I gain by moving it out of the Customer, making it a VALUE OBJECT, and then referencing the VALUE OBJECT back in the Customer? Please cite some practical example.

  2. Can SPECIFICATIONS be used on VALUE OBJECTS too?

  3. Are all properties of ENTITY OBJECTS either other ENTITY OBJECTS and/or VALUE OBJECTS? Or can they have primitives?

  4. Browsing the internet, I've seen some saying that setters (and getters?) are evil, that they should be avoided and replaced by operations that makes sense for the domain object.

For example:

Account.Balance = 100;  // set via property setter

Should be:

Account.DebitToAccount(100); // this would change the balance

In this example, I can understand what they are implying but what about for some common properties like FirstName, MiddleName, LastName? I think it's tedious and pointless to have methods for each property just to set them (like ChangeName()). And assuming that we've chosen to have a method like ChangeName(), what about for properties that have no other groupable property? For example, say Title? Should we have a ChangeTitle() too? (Title is just an example, please don't say that I can group Title to some other property)

1
domain-driven-designvalue-objects

1 Answers

1
votes

  1. Encapsulation of a domain concept. An Address is not just any string , a Price is not any number/decimal . VO represents a valid value of a Domain concept expressed as an object. Note that 'a' value doesn't really mean encapsulation of 1 primitive. You can see here an example of how I've modeled some value objects.

  2. No.

  3. It's not a rule. A property of an entity should be of type that makes more sense. Some represent domain concepts, other represent more general concepts (like Email) and other are just primitives.

  4. Not really DDD, that's proper OOP. The point is you want to encapsulate behaviour. Setting a property is just a simple assignment. DebitToAccount is a semantic behaviour of the object that may be implemented only as a property assignment. Things can easily change and you want only that object to know about those implementation details. The behaviour itself stays, implementation can change anytime (ex: a new business rule is required).

At least in C# you don't really need ChangeName(), you can put the implementation in a setter. There aren't rules, not even principles in this scenario, it depends on developer style.