Objets de domaine et objets de valeur - sont-ils égaux?

Question

En regardant l'exemple d'un objet de domaine dans le didacticiel Zend QuickStart, et d'autres exemples en tenant compte des modèles DAO / VO, ils semblent tous deux très similaires.

Pouvons-nous déduire cela à dire "Objet de valeur" est le même que de dire "objet de domaine"?

Sinon, pouvez-vous s'il vous plaît clarifier les différences entre celles-ci?

Quelle est la fonction de une, et si la fonction d'une autre?

Je demande ceci parce que les deux sont composés par Getters et Setters et rien de plus que cela. Il semble que ils font la même fonction ...

Mise à jour:

Ainsi, la documentation du didacticiel rapide du framework zend appelé ceci, un objet de domaine:

 // 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) À proprement parler, sommes-nous face à un "objet de domaine anémique"?

2) Est-il appelé "objet de domaine" juste Parce qu'il contient une logique de domaine?

3) Si tel est le cas, alors, ces mappeurs contenant des méthodes comme FindBookByAuthor (); Ils traitent également de la logique du domaine, non? Pourraient-ils également être considérés comme des objets de domaine?

Merci beaucoup

Answer 1

En règle générale, un objet de valeur résume quelque chose qui a une valeur: monnaie, dates, température, etc. Ils peuvent contenir une valeur et des unités, mais ils ne sont pas complexes.

Un objet de domaine est susceptible d'être plus complexe (sauf s'il s'agit d'un objet de domaine anémique, qui est un tas de getters et de setters faisant semblant d'être un objet de domaine) car il contient une logique de domaine.

Par exemple, vous pouvez avoir un objet de domaine de facture qui contient de nombreuses lignes de facture (une ligne pour chaque élément de facture), et chaque ligne de facture peut avoir un montant net, un montant d'impôt et un élément de facture. Les montants et peut-être que l'élément de facture serait généralement de valeur des objets et serait raisonnablement simple.

La facture elle-même pourrait être compliquée avec les taux d'intérêt pour le paiement tardif, la prise en charge d'un processus d'approbation ou la prise en charge de votre système comptable.

L'objet de valeur est assez simple pour être réutilisable sur différents domaines. Les objets de domaine modélisent votre domaine réel et sont généralement écrits pour modéliser votre entreprise ou votre domaine spécifique, y compris votre logique métier.

La raison pour laquelle vous verrez souvent peu de différence entre eux est que de nombreux développeurs utiliseront une conception d'objets de script / transfert de données de transaction, mais l'appellent un modèle de domaine. Ils étiquettent leurs collections de Getters et Setters "Objets de domaine".

Answer 2

Ils boîte être la même chose. Et dans de nombreux cas, ils le sont. Cependant:

• Les objets de domaine peuvent effectuer une logique métier (selon la conception axée sur le domaine au moins), les objets de valeur ne peuvent pas
• Les objets de domaine ont toutes les informations, tandis que les objets de valeur ne contiennent qu'une partie des informations pertinentes pour son consommateur.

Par exemple, en cas de Invoice Objet Domain, ce sera le même que l'objet de valeur, puis vous pouvez utiliser la même classe pour les deux - il aura un numéro de facture, des articles commandés, un prix total.

D'un autre côté, un User L'objet Domain aura un champ de mot de passe et un champ de messagerie, que vous souhaitez pouvoir traiter dans votre système, mais vous ne devriez jamais envoyer à d'autres systèmes. Par conséquent, vous avez besoin d'un nouvel objet de valeur, qui n'a pas ces deux champs.

Answer 3

S'appuyant sur les réponses précédentes, je suis d'avis qu'ils sont ne pas le même:

1. Les objets de domaine peuvent contenir une logique métier. Ils représentent des entités dans l'espace de problème, leur valeur de propriété peut être modifiée et est identifiée par un ID unique.
2. Selon le gang de quatre, valeur les objets sont immuables. Ces objets ne sont identifiés par aucun ID, mais plutôt par leur valeur.