Faire face à un modèle de domaine anémique

Question

J'essayais de séparer mon DAL de ma couche de gestion et, ce faisant, j'ai décidé d'éviter toute approche ActiveRecord et d'adopter une approche DataMapper. En d'autres termes, mes objets de domaine ne prendraient pas soin de se maintenir. Ce faisant, il semble que j'empiète sur le "modèle du domaine anémique". anti-motif. Par exemple, une des entités de mon programme est une organisation.

Une organisation est représentée sous la forme suivante:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

En gros, cette organisation ne fait rien d'autre que d'agir comme un "sac". (comme le dit Martin Fowler) pour certaines données. Dans le monde PHP, ce n'est rien d'autre qu'un tableau glorifié. Aucun comportement n'y est associé.

Et en ce qui concerne le comportement dans le programme, j'ai bloqué le "niveau de service". classe comme un service d'organisation qui sert principalement d'intermédiaire entre ces objets et le DAL.

Hormis les problèmes potentiels de redimensionnement avec PHP (j’ai d’autres raisons pour insister pour "mettre en sac" mes données dans ces objets), cette approche est-elle totalement hors service?

Comment gérez-vous vos modèles de domaine dans ces situations? Peut-être une organisation ne fait-elle pas partie de mon domaine?

Answer 1

Eh bien, cela semble être le cas au début, mais lorsque vous refactoriserez davantage votre code, vous obtiendrez un comportement pour votre classe d'organisation ...

Un exemple auquel je pourrais penser maintenant est que si vous avez des personnes (employés), vous pouvez les associer à une organisation. alors, vous pourriez avoir une méthode AssociateEmployee (employé utilisateur) qui pourrait trouver sa place dans votre classe d'organisation.

Vous pouvez également modifier l'emplacement de la société. Au lieu de définir des paramètres tels que l'adresse, la ville, l'état en trois étapes, vous pouvez ajouter la méthode ChangeLocation (Rue, Ville, État) .

Allez-y étape par étape. Lorsque vous rencontrez du code dans votre couche de service BL / qui semble appartenir au domaine, déplacez-le vers le domaine. Si vous lisez Fowler, vous l’obtiendrez très bientôt lorsque vous le verrez dans votre code.

Answer 2

Cela pourrait bien être une anémie maintenant?

Par exemple, j’avais déjà développé un site d’enregistrement de réunions / conférences. Cela a commencé avec une seule réunion.

Il y avait toujours une classe de réunion et un seul cas, mais l'année suivante, nous avons organisé la conférence, elle a été agrandie et de nouvelles propriétés ont été ajoutées (pour tenir deux réunions consécutives). encore développé, car nous avons ensuite ajouté des groupes de réunion pouvant contenir plusieurs réunions.

Je pense donc qu'il est important de garder à l'esprit que les domaines changent avec le temps et que votre modèle risque d'être refactoré. Ainsi, même si vous pensez que c'est anémique, il se peut qu'il soit un peu trop prospectif (comme votre classe d'organisation). commencera à obtenir des paramètres, des règles ou des préférences ou quelque chose comme ça).

Answer 3

Vous pouvez également considérer que si vous n'avez pas beaucoup de règles métier, ou si le domaine n'est pas si complexe, le DDD peut être trop coûteux pour vous. DDD est une excellente solution pour les domaines vastes et compliqués, mais nécessite beaucoup de travail et de complexité si vous importez simplement des données. DDD est plus difficile à concevoir et ajoute naturellement de la complexité. Par conséquent, pour le justifier, la complexité du domaine problématique doit l’emporter sur celle-là.

C'est tout ce que je voudrais ajouter à zappan et à epitka.

Answer 4

Votre entité n'est pas anémique, car vous prenez une stratégie de reprise qui ne devrait pas être là pour commencer. La persistance et la récupération des entités sont la responsabilité des référentiels. Vraiment, votre comportement devrait être dans vos entités et non dans une couche de service. Mais expliquer ce qui se passe est bien au-delà de la simple réponse. DDD d’Eric Evans est un bon point de départ.