0

In his book, Eric Evans distinguishes between value classes and entity classes. Value objects do not have an identity and continuity.

Do Value classes contain behaviour? Is it acceptable for Value Types not to have behaviour? The reason I ask is because a rich domain model differs from an anemic one in the sense that classes contain state and behaviour. I am trying to create a rich domain model, however I am finding myself creating value objects with no behaviour.

Therefore I wonder if my domain model is anemic (because the value types do not contain behaviour) and rich (because the entity types do contain behaviour).

  • 1
    I understand, I know, that's why I pointed you to the second part of the answer: "A Value object has behavior (behavior for read). For example, it implements the behavoir to test if two value objects are equal or not." – Constantin Galbenu Jun 14 '17 at 12:00
  • 1
    @TSar Eric Evans's and Vaughn Vernon's sect says that they should be immutable. – Constantin Galbenu Jun 14 '17 at 12:09
  • 1
    @ConstantinGALBENU I'm not saying it's not useful. However, one can find use cases for mutable value objects, and several other types of worker objects that hold a temporary, volatile, state but have no persistent identity. Sometimes the mutability having side effects is desirable. It boils down to what you are trying to implement - having golden rules introducing artificial restraints is a bad thing. I interpret immutable value objects as maybe a gold suggestion as in a generally good idea, but something I can toss away if I can do something in a clearer and more maintainable way otherwise. – T. Sar Jun 14 '17 at 12:25
  • 1
    "* I am trying to create a rich domain model...*" That's the start of your problem, right there. – David Arno Jun 14 '17 at 13:13
  • 1
    @w0051977, I certainly am. The "rotten domain model" forces you down the path of mutating state, which is, in most cases, a "bad thing". – David Arno Jun 14 '17 at 13:20
3

The distinction between value types and entities is largely independent of the amount of behavior that a class has.

  • For entities, it is very unusual that they don't have behavior and that would be almost certainly an indication of an anemic domain model.

  • For value types, you can have them with very rich behavior (like String) or with no behavior at all (typically DTO classes).

If you want to keep away from anemic domain models, then you should avoid entities without behavior. That is, classes where multiple copies of an object shouldn't compare equal but that also don't contain behavior.

  • 1
    Don't force behavior where it doesn't belong, however. It's entirely possible to have one or more entity classes with no behavior at all because they are just that simple - just data containers to be used somewhere else that are persisted in the database. Forcing behavior where shouldn't be none is as bad as putting needed behavior somewhere else. – T. Sar Jun 14 '17 at 12:08
  • Thanks. So value types that do not contain behaviour (only .equals and .hashcode) do not make the domain model anemic? It is entities without behaviour that make a domain model anemic. Have I understood that correctly? – w0051977 Jun 14 '17 at 12:11
  • nitpicking: String is a reference type. – devnull Jun 14 '17 at 12:11
  • @w0051977: Yes, you understand that correctly, but also take the comment from @TSar into account. A few entity classes without behavior is not a problem, but the majority without behavior is.` – Bart van Ingen Schenau Jun 14 '17 at 13:56
3

Do Value classes contain behaviour?

Evans, Domain Driven Design

An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT.... Treat the VALUE OBJECT as immutable. Don't give it any identity, and avoid the design complexities necessary to maintain entities.

Value objects are representations of immutable state, using spellings taken from the language of your domain.

Which typically means that they will support queries that return other Value objects, but they won't support any commands, and they won't have any side effects.

Another way of expressing the same idea: they are a remedy against primitive obsession.

They are a way of insulating the domain model from the details of the underlying data model.

In object oriented programming, "behavior" is normally associated with a change of state. So no, a Value object doesn't do that. Typically, instead of changing itself, what the value object will do is return a new immutable object describing the same state.

For instance, consider List.add(...)

If List is an entity, then the usual implementation of add is to mutate the internal representation of the list (ie, the data structure hidden behind the abstraction).

List theList = List.of(1,2,3)
assert theList.size() == 3

theList.add(4);
assert theList.size() == 4

If List is a value object, then the usual implementation of add returns a new List object without changing the original.

List source = List.of(1,2,3)
assert source.size() == 3

List target = source.add(4)
assert target.size() == 4
assert source.size() == 3
2

Anemia does not make sense in the context of Value objects, but in the context of Entities, especially Aggregates.

However, Value objects can have some kinds of behavior (like formatting, conversions, computations) but the purpose of that behavior is different from the behavior found in Entities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.