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." Jun 14, 2017 at 12:00
  • 1
    @TSar Eric Evans's and Vaughn Vernon's sect says that they should be immutable. Jun 14, 2017 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, 2017 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, 2017 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, 2017 at 13:20

3 Answers 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.

  • 2
    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, 2017 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, 2017 at 12:11
  • nitpicking: String is a reference type.
    – devnull
    Jun 14, 2017 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.` Jun 14, 2017 at 13:56

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

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
  • if I need to export the content of my Value Object to a csv file. Can I put a method inside my own VO or is it better to have a separated class for csv operations?
    – danilo
    Dec 9, 2019 at 21:21
  • "Create a csv representation of this data" doesn't sound like a domain concern, so Evans would probably suggest that the implementation belongs somewhere else. Your CSV data is a kind of message, and the schema for that message may belong closer to the boundary. Your domain model is harder to change when your domain code is mixed with a bunch of non domain concerns. Changes that affect both the domain model and your messaging are easier when those concerns are close together. Take a guess, keep track of how it turns out. Dec 9, 2019 at 23:04

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 and acknowledge you have read our privacy policy.

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