Domain Objects and Value Objects - are they equal?

Question

By looking to the example of a Domain Object into Zend Quickstart tutorial, and other examples considering a DAO/VO patterns, they both seem to be very similar.

Can we deduce that to say "Value Object" is the same as to say "Domain Object" ?

If not, can you please clarify the differences between those?

What is the function of one, and what if the function of another ?

I'm asking this because, both are composed by getters and setters and nothing more then that. It seems that, they do the same function...

Update:

So, Zend Framework Quick Tutorial documentation called this, a domain object:

 // application/models/Guestbook.php

    class Application_Model_Guestbook
    {
        protected $_comment;
        protected $_created;
        protected $_email;
        protected $_id;

        public function __construct(array $options = null)
        {
            if (is_array($options)) {
                $this->setOptions($options);
            }
        }

        public function __set($name, $value)
        {
            $method = 'set' . $name;
            if (('mapper' == $name) || !method_exists($this, $method)) {
                throw new Exception('Invalid guestbook property');
            }
            $this->$method($value);
        }

        public function __get($name)
        {
            $method = 'get' . $name;
            if (('mapper' == $name) || !method_exists($this, $method)) {
                throw new Exception('Invalid guestbook property');
            }
            return $this->$method();
        }

        public function setOptions(array $options)
        {
            $methods = get_class_methods($this);
            foreach ($options as $key => $value) {
                $method = 'set' . ucfirst($key);
                if (in_array($method, $methods)) {
                    $this->$method($value);
                }
            }
            return $this;
        }

        public function setComment($text)
        {
            $this->_comment = (string) $text;
            return $this;
        }

        public function getComment()
        {
            return $this->_comment;
        }

        public function setEmail($email)
        {
            $this->_email = (string) $email;
            return $this;
        }

        public function getEmail()
        {
            return $this->_email;
        }

        public function setCreated($ts)
        {
            $this->_created = $ts;
            return $this;
        }

        public function getCreated()
        {
            return $this->_created;
        }

        public function setId($id)
        {
            $this->_id = (int) $id;
            return $this;
        }

        public function getId()
        {
            return $this->_id;
        }
    }

1) Strictly speaking, are we in face of a "Anemic Domain Object" ?

2) Is it called "domain object" just because it contains domain logic ?

3) If this is the case, then, those mappers containing methods like findBookByAuthor(); they are also dealing with domain logic right? Could they be considered domain objects as well ?

Thanks a lot

Euryale

Answer 1

Typically a value object encapsulates something that has a value: currency, dates, temperature, etc. They may contain a value and units, but they're not complex.

A domain object is likely to be more complex (unless it's an Anemic Domain Object, which is a bunch of getters and setters pretending to be a domain object) because it contains domain logic.

For example, you might have an Invoice domain object that contains many Invoice Lines (a line for each Invoice Item), and each Invoice Line might have a Net Amount, a Tax Amount, and an Invoice Item. The Amounts and maybe Invoice Item would typically be Value Objects and be reasonably simple.

The Invoice itself could be complicated with interest rates for late payment, support for an approval process, or support for your accounting system.

The Value Object is simple enough to be reusable across different domains. The Domain Objects model your actual domain and are typically written to model your specific business or domain, including your business logic.

The reason you'll often see little difference between them is that many developers will use a Transaction Script/Data Transfer Object design, but call it a Domain Model. They label their collections of getters and setters "domain objects".

Tinnitus

Of course, I'm talking in the generic design pattern sense. YMMV if you're in a community that uses different definitions for those terms. – Tinnitus

Can we say it is wrong to call "Transaction Script/Data Transfer Object design by "Domain Model", UNLESS that are talking in a way that Domain model, means only a "model" of MVC, related to a given domain? – Euryale

I think we need to differentiate between "Domain Model", which is a specific design pattern, and "domain model" or "model", which is a more general term. You can model your domain without using a Domain Model. The M in MVC can be a Domain Model, but also might just be a domain model (or object model, etc.) – Tinnitus

Answer 2

Building on the previous responses, I am of the opinion that they are not the same:

1. Domain objects can contain business logic. They represent entities in the problem space, their property values may be changed and are identified by a unique ID.
2. According to the Gang of Four, Value Objects are immutable. Such objects are not identified by any ID, but instead by their value.

Yod

Answer 3

They can be the same thing. And in many cases they are. However:

• domain objects can perform business logic (according to domain-driven design at least), value objects can't
• domain objects have the whole information, while value objects hold only part of the information that is relevant to its consumer.

For example, in case of an Invoice domain object, it will be same as the value object, and then you can use the same class for both - it will have an invoice number, ordered items, total price.

On the other hand, a User domain object will have a password field and email field, which you want to be able to process within your system, but you should never send to other systems. Hence you need a new, value object, that lacks these two fields.

Takeshi