We have started the third week of the class and this week we are learning about tactical patterns in Domain-driven design for instance, Value Object, Entity, and Aggregate. In addition, as part of our homework, we have started implementing our first Ruby on Rails application with DDD, CQRS, and Event Sourcing.

Let’s start with Value Object.

What is Value Object?

Value object is an immutable object without any history or distinct identity. It is represented and compared by value (combination of its attributes). If you want to change value object you have to create a new instance with new attributes.

Let’s stop here for a moment and try to visualize this concept. We can think about numbers. A number is represented by the value for example, 9 . We do not have any additional identity here. We can add two numbers and we will get a completely new number for example, 9 + 1 = 10 . When we are looking at 10 we do not have any history of changes, we do not know if it was created by adding 5 + 5 or maybe 2 + 8 . After each operation, we have a new instance without any history or distinct identity.

There are many examples of more complex value objects for instance, Amount , VatRate , Position , Deadline , and so on. A simple example of FullName value object can be seen below.

class FullName

include Comparable InvalidValue = Class.new(StandardError) attr_reader :first_name, :last_name def initialize(first_name, last_name)

raise InvalidValue if first_name.blank? || last_name.blank? @first_name = first_name

@last_name = last_name

end def <=>(other)

self.class == other.class &&

first_name == other.first_name &&

last_name == other.last_name ? 0 : -1

end def first_name

first_name

end def last_name

last_name

end def to_s

"#{first_name} #{last_name}"

end

end

What are the benefits of using Value Objects?

Let’s say you want to stop using primitive types for example, String or Integer in one part of the system and start using value objects. Why is it a better approach?

Value objects are very handy for several reasons:

We are able to reduce the number of passed parameters between layers and classes. In the FullName example, we do not have to pass two strings for first name and last name everywhere. Instead, we can use one parameter full_name . Maybe one parameter does not sound like a lot but in a more complex scenario, this number can be much bigger.

example, we do not have to pass two strings for first name and last name everywhere. Instead, we can use one parameter . Maybe one parameter does not sound like a lot but in a more complex scenario, this number can be much bigger. We can have simple validations here for instance, checking if first_name is present or if latitude is not out of bounds. Thanks to that you do not have to wonder if the value is correct or not in other places. If value object was created then it’s correct.

is present or if is not out of bounds. Thanks to that you do not have to wonder if the value is correct or not in other places. If value object was created then it’s correct. Value object is a good place for encapsulating simple logic related to attributes for example, formatting or applying vat rate to the amount and of course all kinds of operations for example, addition, subtraction, and comparison.

Value object is a well-defined unit which represents a small part of our system and thanks to that we can easily test it in one place.

With value objects, we can add more domain/business meaning to our code. We are not using random Integer but Deadline . It has a meaning in our domain. Thanks to that our communication with business people is easier.

Summary

I am using value objects in my projects and it really helped with readability and maintainability of the whole system. I was surprised how some parts of the code can be simplified thanks to this technique.

If you want to see how to implement other DDD patterns in Ruby on Rails you can check out my sample application here.