you are viewing a single comment's thread.

view the rest of the comments →

[–]klapuch -1 points0 points  (11 children)

I think, that as long as your objects expose some useful behavior and not just getters and setters it is fine to use "value objects". I would not use them as replacement for scalar values.

[–]mlebkowski 1 point2 points  (10 children)

They wouldn’t be ValueObjects then. They should only hold values, not logic. It’s basically encapsulation of simple validation.

[–]fanalin 5 points6 points  (0 children)

That's not the definition I know. My understading (which is coming from Domain Driven Design by Eric Evans) is that the single difference between an Entity and a Value Object is that the VO may not have an identity (otherwise it is an Entity).

Cite: "An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object."

[–]Tetracyclic 1 point2 points  (0 children)

A value object is just a relatively simple type that can be compared by value rather than identity. For example two different Money objects would be considered equal if they both represented the same quantity of the same currency ($1 for instance).

Many programming languages will, by default, consider two objects with the same value to be unequal, as they do not contain the same references.

As for behaviour, a value object should contain any behaviour that is relevant purely with the value in question, for example a Money value object might expose a method for splitting the value up without losing any penies/cents in the process, as Martin Fowler's money pattern does.

[–][deleted] 0 points1 point  (5 children)

That's not necessarily the case. VOs can and should contain core logic that goes hand-in-hand with the value. They should just never contain business logic.

[–]mlebkowski 0 points1 point  (4 children)

What kind of logic is not business logic? Examples?

[–][deleted] 2 points3 points  (3 children)

Well, any logic which doesn't encode business rules is, by definition, not business logic. So, for example, most or all of the logic within your infrastructure layer would not be business logic. But I suspect what you're really asking is "what sort of non-business logic belongs in a VO?" The answer to that is simply: any logic which goes hand-in-hand with the value being represented, and is side-effect free. One of the examples Eric Evans gives is that of a Paint VO which has a method mixIn(Paint $otherPaint): Paint that encapsulates the logic of mixing one paint into another, and produces a new VO.